Subject: xCal - time to submit?

From: Doug Royer <[email-masked]>
Date: Fri, 14 Oct 2005 12:59:00 -0600

xCal has been around for quite a while. I have included
the last comments (and they were great feedback).

Is it time to move xCal from draft to RFC status?
This is the 2nd round of xCal. The first was was delayed so
this version re-started at -00 as the other draft-many
had expired.

Please let me know if you have any more issues:

http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt

If not, lets move this to RFC proposed standard.

Thanks!

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Sun, 16 Oct 2005 13:13:13 -0600

Michiel van Leeuwen wrote:
> Doug Royer wrote:
> Why would you want to do that? What is the advantage of adding a new 
> standard?

What new standard? My draft proposes no new components, properties,
parameters, or values. My draft does not propose any change
to any component, property, parameter, or value..

It explicitly states it is a representation if iCal. That's why I
released the XSLT transform to iCal on surceforge prior to this request.
So that it was clear and verifiable that it was a 1:1 mapping of iCal.

> To me, that doesn't seem to simplify things, it just adds more 
> problems. I would just drop the thing, and live with one standard (it 
> might not be a perfect standard, but we need to live with it anyway, 
 > convert all apps and all files out there)

There are TWO OTHER XML calendaring drafts. Perhaps you read one
of the other XML calendar drafts out there? Both of those
other drafts are not a 1:1 mapping to iCal.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Oct 2005 13:04:38 -0600

I may have forgot to set the REPLY-TO the xCal mailing list.
Often others overrode or ignored that.

And we have to post announcements to all related lists, else we are
told to when we ask for final last call.

Aki Niemi wrote:
> Speaking as calsify chair, I'd simply like to point out that this would 
> in any case be strictly an individual effort; XML representation of 
> iCalendar is firmly out of the scope of the calsify WG.
> 
> Cheers,
> Aki
> 

--

---

From: Doug Royer <[email-masked]>
Date: Sat, 22 Oct 2005 14:15:39 -0600

Aki Niemi wrote:
> [Speaking as an individual, not chair.]
> 
> Hi,
> 
> A couple of issues occured to me while reading the draft:
> 
> First, the problem this draft is trying to solve seems approximately the 
> same that MMUSIC aimed at in its SDPng work, in which the idea was to 
> move from the current SDP into an XML based format. Even the core 
> difficulty seems to be the same, namely the huge installed base only 
> supporting the legacy format makes transition a bit hairy.

What move?

What transition?

> Secondly, if we think of xCal as being a next generation iCal format, 

Clearly you have not read the draft. It says:

  	This memo only provides an alternative, XML
    	representation for the standard syntax defined in [iCAL].

No 'Next generation' at all.

If you go to the CALSCH mailing list archives you can see that other
non-1:1 mappings of iCal were NOT desired and discouraged by the IESG.

> wouldn't it be more beneficial to design it from scratch instead of 
> simply doing a 1:1 syntactic transform?

Fell free to submit such a draft. The xCal draft allow iCal
data "as defined in iCal to be mixed with XML data.

The rest of your email seems to repeat your above point.

--

---

From: Dave Cridland <[email-masked]>
Date: Sun, 23 Oct 2005 14:57:39 +0100

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.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Doug Royer <[email-masked]>
Date: Sun, 23 Oct 2005 08:36:41 -0600

Aki Niemi wrote:
> [Speaking as individual again]
> 
> Inline.
> 
> ext Doug Royer wrote:
> 
>>
>>
>> Aki Niemi wrote:
>>
>>> First, the problem this draft is trying to solve seems approximately 
>>> the same that MMUSIC aimed at in its SDPng work, in which the idea 
>>> was to move from the current SDP into an XML based format. Even the 
>>> core difficulty seems to be the same, namely the huge installed base 
>>> only supporting the legacy format makes transition a bit hairy. 
>>
>>
>> What move?
> 
> 

What new one? xCal is YEARS old.

Its clear that you have not really read xCal. And it is clear
that you are not interested in discussing any real points in the draft.

--