headers
Internet-Drafts | 3 Jul 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-calsify-rfc2445bis-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-01.txt
	Pages		: 156
	Date		: 2006-6-23
	
There is a clear need to provide and deploy interoperable calendaring
and scheduling services for the Internet.  Current group scheduling
and Personal Information Management (PIM) products are being extended
for use across the Internet, today, in proprietary ways.  This memo
has been defined to provide the definition of a common format for
openly exchanging calendaring and scheduling information across the
Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsify-rfc2445bis-01.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eliot Lear | 15 Jul 2006 05:39
Picon
Favicon

Re: [issue21] do we need a new mime type for this update, in order for backward compat?

Alexey Melnikov wrote:
> Eliot Lear wrote:
>
>> New submission from Eliot Lear <lear <at> ofcourseimright.com>:
>>
>> if we've preserved backward compat then we don't need this. 
>> otherwise we might.
>>  
>>
> I thought rfc2445bis took care of this (it registers the MIME type,
> used by iTIP and iMIP)?
>
I know it does currently, and perhaps I've misplaced the issue, but it
seemed more natural for iMIP.  This issue is a placeholder.  If we make
incompatible or substantial changes by the time we're done, we should
think about how this could be managed by calendar systems.  One approach
is to use mime multipart/alternative with a new version.  Another
approach would be to bump the iCal version number.  This is not
something we can decide until we're a little further down the road, but
we should consider it.

Eliot
Permalink | Reply | 1 comment |
headers
Tim Hare | 15 Jul 2006 16:47
Picon

RE: Re: [issue21] do we need a new mime type for this update, in order for backward compat?

I don't know about the version number - in my experimentation with some
different implementations, some of them seem to ignore the VERSION:
component entirely; if the MIME type is text/calendar or the file extension
is ".ics" they read the file as though it were "VERSION: 2.0" even if the
VERSION: component is "1.0".

I agree with the statement "if we've preserved backward compat then we don't
need this".  I believe one of the original goals of Calsify was to reach a
sort of "least common denominator" that could be used without breaking
existing implementations badly enough to cause major redevelopment efforts.
I still think that's a good idea, and so would not like to see incompatible
or substantial changes. 

In my opinion, if you change things significantly enough to cause those
kinds of problems, you might as well go ahead and change over to an
XML-based syntax while you're at it: at least with XML you could fairly
easily invoke a parser and stylesheet in your input pipeline to transform it
into whatever your implementation understands.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: ietf-calsify-bounces <at> osafoundation.org
[mailto:ietf-calsify-bounces <at> osafoundation.org] On Behalf Of Eliot Lear
Sent: Friday, July 14, 2006 11:39 PM
To: Alexey Melnikov
Cc: ietf-calsify <at> osafoundation.org
Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this
update, in order for backward compat?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 21 Jul 2006 18:00
Favicon

2445bis: clarify allowed value types of date-time property combinations

Hi Bernard,
I was just checking on the behavior for the VALUE type of DTSTART/DTEND and 
DTSTART/DUE in VEVENT and VTODO. Right now for VEVENT, the only restriction 
I see is that if DTSTART is a DATE then DTEND must also be a DATE. That 
means that having DTSTART be DATE-TIME and DTEND be DATE is allowed 
(provided DTEND is later than DTSTART). If that is allowed then I would 
like to see it explicitly stated - perhaps a table of the two properties 
with yes/no for combinations of value types?

The issue with VTODO is more complex as there is no restriction at all, so 
DTSTART as DATE and DUE as DATE-TIME, or DTSTART as DATE-TIME and DUE as 
DATE is allowed. I was just bitten by this so would like to see more 
clarification as per VEVENT.

PS This might tie in with the UNTIL value issue too. Perhaps a table of all 
date/time related properties for each component with an indication of what 
combinations of values each is allowed would be good.

--

-- 
Cyrus Daboo
Permalink | Reply | 0 comments |
headers
IESG Secretary | 25 Jul 2006 22:00
Picon
Favicon

WG Action: RECHARTER: Calendaring and Scheduling Standards Simplification (calsify)

The charter of the Calendaring and Scheduling Standards Simplification 
(calsify) working group in the Applications Area of the IETF has been 
updated. For additional information, please contact the Area Directors or the 
working group Chairs.

+++

Calendaring and Scheduling Standards Simplification (calsify)
==============================================================

Current Status: Active Working Group

Chair(s):
Eliot Lear <lear <at> cisco.com>
Aki Niemi <aki.niemi <at> nokia.com>

Applications Area Director(s):
Ted Hardie <hardie <at> qualcomm.com>
Lisa Dusseault <lisa <at> osafoundation.org>

Applications Area Advisor:
Lisa Dusseault <lisa <at> osafoundation.org>

Mailing Lists:
General Discussion: ietf-calsify <at> osafoundation.org
To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/

Description of Working Group:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lisa Dusseault | 26 Jul 2006 02:24
Favicon

RRule simplification for interpersonal calendar GUIs


I would like to consider whether RRules are too complicated for GUI  
display in our most common calendar client applications.  If I send a  
complex RRule event to you and your client can't display the RRule in  
its GUI, you can only accept or reject the request, not modify it,  
and possibly not even understand it well.   Worse, if I'm using  
CalDAV and one client creates a complex RRule but then I switch to  
another client, I risk having a recurring event that I can't  
manage.   Shared calendars are particularly subject to this problem.

Although RRules may need to be powerful for certain situations  
(timezones), I believe they're too complex for use in events in GUIs  
designed for personal calendaring.  As an exercise, I took Apple's  
iCal, the most powerful recurrence-rule generating GUI available to  
me at this time on this computer, and tried to discover the full  
range of RRules I could create.  I also searched the Web for  
instances of certain kinds of RRules (e.g. looking at IETF meeting  
ICS files and similar shared files and googling for BYWEEKNO.) The  
kinds of RRules that I couldn't find "in the wild" or create, we  
should consider discouraging for interpersonal calendaring.

I don't care if we repeat the exercise for some other GUI client or  
make changes on what some other GUI client can do; this first attempt  
illustrates the approach rather than limits it.

My personal opinion is that some kind of simplification is required  
for two big reasons:
	- To improve interoperability between clients that attempt to do a  
decent job of RRules
	- To encourage clients that currently don't do RRules (many mobile
(Continue reading)

Permalink | Reply | 26 comments |
headers
Andrew N Dowden | 26 Jul 2006 02:52
Picon

Re: RRule simplification for interpersonal calendar GUIs

Lisa Dusseault wrote:
> I would like to consider whether RRules are too complicated for GUI
> display in our most common calendar client applications.  If I send a
> complex RRule event to you and your client can't display the RRule in
> its GUI, you can only accept or reject the request, not modify it, and
> possibly not even understand it well.   Worse, if I'm using CalDAV and
> one client creates a complex RRule but then I switch to another
> client, I risk having a recurring event that I can't manage.   Shared
> calendars are particularly subject to this problem.
I have carried out similar research in the context of discussions /
advise within the  Mozilla Sunbird / Lightning  project.  It will take a
little time to review your submission, and respond.  In general, I agree
some guidance on this issue (as it impact on GUI feature sets) it
definitely required.  I am unsure if your approach in necessarily the
best way to deal with this problem.

More detailed comment to follow (time permitting) ..

I also have a set of  iCalendar  files for NZ, US and Canada public
holidays, and other 'more complex' use of RRULE's that I have used as
the basis for my  GUI design  proposals.  They may also be of interest
in this discussion / thread.

--

-- 
_______________________________________________

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tantek Çelik | 26 Jul 2006 03:01
Favicon

Re: RRule simplification for interpersonal calendar GUIs

On Jul 25, 2006, at 5:24 PM, Lisa Dusseault wrote:

> The kinds of RRules that I couldn't find "in the wild" or create, we 
> should consider discouraging for interpersonal calendaring.

I *strongly* agree with this methodology.

Too much of RRULE in 2445 appears to have been designed to reach some 
sort of mathematical completeness goal in terms of recurrence, instead 
of based on the actual 80/20 usage of recurring meetings in the real 
world.

> I don't care if we repeat the exercise for some other GUI client or 
> make changes on what some other GUI client can do; this first attempt 
> illustrates the approach rather than limits it.
>
> My personal opinion is that some kind of simplification is required 
> for two big reasons:
> 	- To improve interoperability between clients that attempt to do a 
> decent job of RRules
> 	- To encourage clients that currently don't do RRules (many mobile 
> devices) to implement.  Let's meet them half-way with  recurrence 
> functionality that's simple enough for them to implement, and if they 
> implement anything they're more likely to implement the whole set if 
> it's that simple.
>
> Besides GUI display concerns, I had a couple more minor reasons which 
> you can find inside the proposal.
>
> <recur-simplification.txt>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pat R Egen | 26 Jul 2006 03:03

Re: RRule simplification for interpersonal calendar GUIs


Andrew, I'd be interested in your set of iCalendar files to use as part of our Calconnect Interoperability testing.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Andrew N Dowden <andrew_dowden <at> softdesign.net.nz>
Sent by: ietf-calsify-bounces <at> osafoundation.org

07/25/2006 08:52 PM

To
 ietf-calsify <at> osafoundation.org
cc
Subject
 Re: [Ietf-calsify] RRule simplification for interpersonal calendar        GUIs





Lisa Dusseault wrote:
> I would like to consider whether RRules are too complicated for GUI
> display in our most common calendar client applications.  If I send a
> complex RRule event to you and your client can't display the RRule in
> its GUI, you can only accept or reject the request, not modify it, and
> possibly not even understand it well.   Worse, if I'm using CalDAV and
> one client creates a complex RRule but then I switch to another
> client, I risk having a recurring event that I can't manage.   Shared
> calendars are particularly subject to this problem.
I have carried out similar research in the context of discussions /
advise within the  Mozilla Sunbird / Lightning  project.  It will take a
little time to review your submission, and respond.  In general, I agree
some guidance on this issue (as it impact on GUI feature sets) it
definitely required.  I am unsure if your approach in necessarily the
best way to deal with this problem.

More detailed comment to follow (time permitting) ..

I also have a set of  iCalendar  files for NZ, US and Canada public
holidays, and other 'more complex' use of RRULE's that I have used as
the basis for my  GUI design  proposals.  They may also be of interest
in this discussion / thread.

--
_______________________________________________

 SoftDesign Group
 Dowden Software Associates
 P O Box 31 132, Lower Hutt 5040, NEW ZEALAND


_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 0 comments |
headers
Chuck Norris | 26 Jul 2006 03:50

Re: RRule simplification for interpersonal calendar GUIs

I like this approach, and can't find anything I would add or change  
about your conclusions.  It certainly meets all of our needs, and  
limiting to this set would make my life a lot easier.

Chuck

On Jul 25, 2006, at 5:24 PM, Lisa Dusseault wrote:

>
> I would like to consider whether RRules are too complicated for GUI  
> display in our most common calendar client applications.  If I send  
> a complex RRule event to you and your client can't display the  
> RRule in its GUI, you can only accept or reject the request, not  
> modify it, and possibly not even understand it well.   Worse, if  
> I'm using CalDAV and one client creates a complex RRule but then I  
> switch to another client, I risk having a recurring event that I  
> can't manage.   Shared calendars are particularly subject to this  
> problem.
>
> Although RRules may need to be powerful for certain situations  
> (timezones), I believe they're too complex for use in events in  
> GUIs designed for personal calendaring.  As an exercise, I took  
> Apple's iCal, the most powerful recurrence-rule generating GUI  
> available to me at this time on this computer, and tried to  
> discover the full range of RRules I could create.  I also searched  
> the Web for instances of certain kinds of RRules (e.g. looking at  
> IETF meeting ICS files and similar shared files and googling for  
> BYWEEKNO.) The kinds of RRules that I couldn't find "in the wild"  
> or create, we should consider discouraging for interpersonal  
> calendaring.
>
> I don't care if we repeat the exercise for some other GUI client or  
> make changes on what some other GUI client can do; this first  
> attempt illustrates the approach rather than limits it.
>
> My personal opinion is that some kind of simplification is required  
> for two big reasons:
> 	- To improve interoperability between clients that attempt to do a  
> decent job of RRules
> 	- To encourage clients that currently don't do RRules (many mobile  
> devices) to implement.  Let's meet them half-way with  recurrence  
> functionality that's simple enough for them to implement, and if  
> they implement anything they're more likely to implement the whole  
> set if it's that simple.
>
> Besides GUI display concerns, I had a couple more minor reasons  
> which you can find inside the proposal.
>
> <recur-simplification.txt>
>
> Feedback?
>
> thanks!
> Lisa_______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify <at> osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 0 comments |

Gmane