Subject: [Ietf-calsify] xCal - time to submit?

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 14 11:59:22 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051014/1cc3ba8f/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Sun Oct 16 02:00:16 2005

Doug Royer wrote:
> Is it time to move xCal from draft to RFC status?

Why would you want to do that? What is the advantage of adding a new 
standard? 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, 
adding a new one won't suddenly convert all apps and all files out there)

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Oct 16 12:13:38 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051016/fe5aed25/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Sun Oct 16 13:26:18 2005

Doug Royer wrote:
> It explicitly states it is a representation if iCal.

It's a new representation. That is the new part. For an app, it is not 
enough to just be able to read 'old' iCalendar files, but now they also 
need an xml parser and parse xCal. And with new things come new bugs and 
new problems.

And in the light of calsify: Having two ways to represent that same data 
doesn't make things simpler. You need to choose one format, and be able 
to read both. More sources of interop problems.

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

Yeah, those formats might be even a bigger problem, but imo that isn't a 
reason to have xCal.

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Oct 16 13:37:09 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051016/e3f54d06/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Oct 17 09:13:11 2005

Doug Royer wrote:
> Why do you say that non-xml applications need need to support xml?
> The draft clearly explains that they must be shipped with iCal objects.

IT says so, but that isn't always possible. For example all the ical 
share websites, or other ways you can share a calendar. You can't use 
multipart/alternative on a webserver.

> And it shows how to mix the standard iCal data with other XML objects,
> this is the reason of also having an XML representation of iCal data.

That's nice, but it doesn't simplify things. And I thought that was the 
goal of calsify. So we have to find the balance between simplifying and 
adding more features. I vote for simplify.

Michiel

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Mon Oct 17 09:37:10 2005

On 17. Okt 2005, at 18:08 Uhr, Michiel van Leeuwen wrote:
> For example all the ical share websites, or other ways you can  
> share a calendar. You can't use multipart/alternative on a webserver.

You accomplish the same thing using content negotiation in HTTP, that  
is "accept: text/xml" vs "accept: text/iCalendar" (or both, or both  
including content preference, say: "accept: text/xml, q=1.0; text/ 
calendar, q=0.5;").

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Oct 17 09:48:22 2005

Helge Hess wrote:
>> For example all the ical share websites, or other ways you can share a 
>> calendar. You can't use multipart/alternative on a webserver.
> 
> You accomplish the same thing using content negotiation in HTTP, that is 
> "accept: text/xml" vs "accept: text/iCalendar" (or both, or both 
> including content preference, say: "accept: text/xml, q=1.0; 
> text/calendar, q=0.5;").

Ok, I didn't think of it. And the spec doesn't mention it (While it does 
mention multipart/alternative.) It might be worth adding it.

But even then, for the best interop, any app need to be able to consume 
both, and only produce the most common format, iCalendar. I still don't 
see the advantage of xCal in the light of calsify.

Michiel

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Fri Oct 21 09:20:56 2005

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

ext Doug Royer wrote:
> 
> 
> xCal has been around for quite a while. I have included
> the last comments (and they were great feedback).
> 
> 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!
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 21 12:04:50 2005

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.

-- 

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

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051021/e9a9acd8/smime.bin

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Sat Oct 22 09:14:06 2005

Nevertheless, your original message had calsify WG in the To header field.

My reply was simply a reminder, that that particular IETF WG (being the 
only active IETF WG addressed) is not responsible for this work, and 
that any submission of xCal to the IESG is by an *individual* and not 
endorsed by the working group. That's all.

Cheers,
Aki

ext Doug Royer 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: aki.niemi at nokia.com (Aki Niemi)
Date: Sat Oct 22 12:44:46 2005

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

Secondly, if we think of xCal as being a next generation iCal format, 
wouldn't it be more beneficial to design it from scratch instead of 
simply doing a 1:1 syntactic transform? After all, XML offers a lot of 
additional features that could be leveraged when doing a "better" 
calendar format.

A very simple example: rather than using "x-" prefix for private 
extensions, standard XML techniques could be used, i.e., putting the 
private extension element under a private (different) XML namespace.

This really boils down to "why?". What benefit is there to define this 
iCal to XML transformation? Because XML is cool is not enough, IMO, 
there needs to be some real benefits as well, especially when there is 
this huge existing installed base for iCal.

Having said all this, this might still be interesting work for even the 
IETF to take on, but I strongly feel this work would benefit from a much 
wider audience. Perhaps in the form of some comments and experiences 
from the MMUSIC WG, and probably a few thoughts from the XML "mafia" of 
the IETF as well.

Personally, I think this ought to be aiming at a BoF rather than an 
individual submission to the IESG.

Cheers,
Aki

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Oct 22 13:15:44 2005

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

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

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051022/fc2af820/smime.bin

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Sun Oct 23 05:28:47 2005

[Speaking as individual again]

Inline.

ext Doug Royer 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 

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?

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

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

> 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

---

From: dave at cridland.net (Dave Cridland)
Date: Sun Oct 23 06:57:46 2005

On Sun Oct 23 13:28:11 2005, Aki Niemi wrote:
> 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 at Royer.com (Doug Royer)
Date: Sun Oct 23 07:37:03 2005

Aki Niemi wrote:
>>> 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.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051023/7398b497/smime-0001.bin