Re: xCal - time to submit?

[Speaking as individual again]

Inline.

ext Doug Royer wrote:
> 
> 
> 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?

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 thought you were familiar with these issues since the draft talks 
about them as well.

In the draft you suggest using multipart/alternative as a transitional 
mechanism. I find that solution lacking, in that will there ever be a 
time when apps can stop using MIME multipart, and simply use the xCal 
MIME type alone? Is that even the intention? If not, what is the benefit 
in defining this alternative format, if the only practical result is 
bloated message payload?

Your draft also says:

    XML
    applications conforming to this specification MUST be able to
    properly parse and process a MIME multipart entity containing the
    MIME type associated with this iCalendar XML document type.

Which is nice, but does not help at all. It is the legacy iCalendar 
application that would need to support MIME multiparts, in order for 
this "transition" to work. A big number does, but probably not all; how 
is this handled?

>> Secondly, if we think of xCal as being a next generation iCal format, 
> 
> Clearly you have not read the draft. It says:

I consider this type of statement quite a weak form of argument in 
general. If something does not come across well in a draft, often the 
reader is not at fault, but the draft needs improvement.

Believe me, I read the draft. I would not be shooting my mouth off if I 
hadn't. :)

>      This memo only provides an alternative, XML
>        representation for the standard syntax defined in [iCAL].
> 
> No 'Next generation' at all.

Why is this then needed at all? As I said in my previous post, because 
XML is cool is not a good enough reason. If it was, then I'm sure the 
ASN.1 constituent would deserve a format as well, followed by a league 
of other groups that like their data representation scheme the best.

Your draft doesn't explain this point, and I think it really should.

> 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.

I see, was a reason given? Should this discussion appear in the draft? 
It would really help those of us who have not followed calsch in the 
past in detail

Cheers,
Aki