Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position

From: [email-masked]
Date: Fri, 15 Oct 1999 09:38:24 -0400

OK, now I feel better. I knew we were trying to help and I can understand 
the language issues raised by Par.  We have the same issues trying to 
understand Swedish.  Maybe we can figure out some way to help out.  I wish 
we got more comments from other people besides Frank and Doug.  It's hard 
to judge the response to a draft if no one makes suggestions.

---

From: [email-masked] (Steve Mansour)
Date: Fri, 15 Oct 1999 08:39:00 -0700

[email-masked] wrote:

> OK, now I feel better. I knew we were trying to help and I can
> understand the language issues raised by Par.  We have the same issues
> trying to understand Swedish.  Maybe we can figure out some way to
> help out.  I wish we got more comments from other people besides Frank
> and Doug.  It's hard to judge the response to a draft if no one makes
> suggestions.

I've been following this thread loosely. I've skimmed the SKiCal draft,
but I have not had the time to give it a thorough review -I will try to
do so before the upcoming IETF meeting.

Here's another perspective on the question of "do we need this stuff in
iCal".  In the last couple of months, I have spoken with a bunch of
event content providers.  Today, they all publish event information in
their own formats (typically some variant of CSV). I have been pushing
them to adopt iCalendar as a standard way to distribute their
information. They are interested at first, I point them to RFC 2445, but
there are _always_ calls a few days later asking how to map fields which
they consider important into the iCalendar schema. It usually turns out
that information is dropped because there's no good way to represent it,
or it gets crammed into a field like DESCRIPTION.  But even that doesn't
always work. Sometimes there are events which will happen "sometime
during the week of October 11 - 15, and it will be 2 hours long, we'll
get back to you when we know the exact date and time". For events like
this, they want to let people know it's coming, and they want to update
it later when they actually know when it is, and after they look at
iCalendar they're not sure how to do it.

The iCalendar schema has worked fine for much of the calendaring and
group scheduling problems with which many of us are familiar. However,
based on the feedback I've been getting from event content providers, it
is not a great fit for their needs --we can shoe-horn the information
into iCalendar but it is a lossy conversion. ICalendar was not designed
with these kind of events in mind. That may have been intentional, or it
may be that event content vendors are just now becoming interested in
standardizing.

I think it would be a good thing for the calendar industry if there were
some standard to accommodate these types of events. At the 50,000 ft
level, it seems like iCalendar is a good place. But I want to do a
detailed review of SKiCal before making a recommendation.

-Steve

---

From: Peter Dickson <[email-masked]>
Date: Fri, 15 Oct 1999 16:27:05 +0100

I would like to get involved but have not participated in this sort of
thing before.

I run a software company in the UK and we want to develop a
calendar/scheduling application (as part of a suite) that uses standard
protocols. I discovered this IETF working group through following links on
Cyrusoft's Mulberry (email client) web site.

How can I get up to speed with what's been happening and, more to the
point, how can I help with taking things forward?

Kind regards

Peter Dickson

--On 15 October 1999, 09:38 -0400 [email-masked] wrote:

> understand Swedish.  Maybe we can figure out some way to help out.  I
> wish we got more comments from other people besides Frank and Doug.  It's
> hard to judge the response to a draft if no one makes suggestions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<mailto:[email-masked]>

Kyros Solutions Ltd           Direct Tel: 0121 683 1329
110 The Custard Factory       Direct Fax: 0870 088 3199
Gibb Street
Birmingham
B9 4AA

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kyros Solutions - passionate about helping people use
information technology effectively  <http://www.kyros.co.uk>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Oct 1999 09:32:29 -0700

> I would like to get involved but have not participated in this sort of

The best way is to just jump in :-)

> point, how can I help with taking things forward?

Comment on the drafts and provide feedback. They REALLY ARE DRAFTS, not
standards. So please provide feedback. That includes questions on 
what you think is broken or not well defined.

RFC2445, RFC2446, and RFC1447 are the base for the CAP draft. I among
others think that there will be more extensions to RFC2445-7. And
they will include work like the SKiCal project.

One thing we (all of us) need to do is to capture the spirit of
RFC2445 in our implementations. There has been some criticism
when extensions are proposed. The objections are often 'my server
will break - I don't know that extension'. Well in my opinion
their server is busted. The iCalendar project will evolve past
RFC2445 and they (we) should design our products knowing that
our applications might not know what all of the extensions mean
all of the time. Yet if a VEVENT PUBLISH is done per RFC2446, it should
not matter if other fields are in the object. It should matter
that the VEVENT PUBLISH meets the minimum requirements of RFC2445 and
RFC2446, the extensions were planned. And implementations should plan
on extensions - not say "I do not know what that property or parameter
does".

If you can attend the IETF meetings that helps, but it is not necessary.

As to getting up to speed - there is never any shortcut. Read and dig in :-)