Subject: [ietf-calsify] Disconnect between icalendar and iTIP mandatory properties

From: Arnaud Quillaud <[email-masked]>
Date: Thu, 22 Jan 2009 17:27:06 +0100

Never noticed it before iTIP validation was added to ical4j but there is 
a disconnect between the mandatory properties specified by iCalendar and 
the ones specified in iTIP REQUESTs.

For VEVENT, the SUMMARY is mandatory in iTIP REQUEST but not in iCalendar.

For VTODO, the DTSTART, PRIORITY and SUMMARY are mandatory in iTIP 
REQUEST but not in iCalendar.

For SUMMARY and PRIORITY, client implementers can always add them with a 
value of null and 0 respectively but for DTSTART, this is more problematic.

When assigning a task to somebody else, it is possible (and actually 
quite likely) that one would set the DUE date and not the DTSTART.

Should we relax this rule ?

Arnaud

PS: In the context of the new CalDAV scheduling draft where automatic 
scheduling takes place as soon as a calendar resource has an organizer 
and attendees, this implicitly means that those calendar resources 
should also have the iTIP mandatory properties.
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 22 Jan 2009 12:30:29 -0500

> Should we relax this rule ?

First off it is OK to impose stricter requirements on components. In the 
case of DTSTART on VTODO I can kind of see the logic of why it might be 
required - but I have no preference either way as to whether we should keep 
it like that.

I should also note that iTIP in fact relaxes iCalendar requirements in some 
cases too. e.g. REPLY/CANCEL of a VEVENT does NOT require DTSTART to be 
present, even though 2445bis now does.

> should also have the iTIP mandatory properties.

We should double-check that there is text in there about whether the 
calendar resources partaking in scheduling are required to properly 
conform to iTIP semantics.

-- 
Cyrus Daboo

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Thu, 22 Jan 2009 10:11:11 -0800 (PST)

> Hello,

would the current date/time be a reasonable value for DTSTART?

Anil

-- 
_______________
Anil SRIVASTAVA  |  [email-masked]  | Sun Microsystems, Inc

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 23 Jan 2009 09:05:22 -0500

Cyrus Daboo wrote:
> Hi Arnaud,
> required

And what would that logic be?

In the absence of a good justification I'd rather have DTSTART optional.

As for SUMMARY and PRIORITY I really think they should be optional.

> - but I have no preference either way as to whether we should keep 
> it like that.
> 

This was addressed in draft -09.  See:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-09.changes.html#rfc.issue.itip-apps-review-issue01

Thanks,
Bernard

---

From: Reinhold Kainhofer <[email-masked]>
Date: Fri, 23 Jan 2009 22:15:26 +0100

> REQUEST but not in iCalendar.

That's a good point. Somehow I had in memory that a DUE would also require a 
DTSTART in a VTODO, however, I can't find anything like that in rfc2445bis any 
more. To the contrary, section "3.8.2.3.  Date/Time Due" explicitly talks of 
the cases where a task has DTSTART set in addition to DUE, so it must also be 
possible to have DUE only. Of course, I might also be missing something in 
rfc2445bis...
That's also the reason why I didn't mention this in my rfc2446 review, since I 
though that rfc2445bis already requires DTSTART when DUE is present.

Of course, recurring VTODOs will need a DTSTART, since the expansion of the 
recurrence set is always based on DTSTART...

Typically a task has a due date but usually no fixed starting date in real 
life, so the requirement to have a start date when you give a due date does 
not really make sense... 

> value of null and 0 respectively but for DTSTART, this is more problematic.

I totally agree.

> quite likely) that one would set the DUE date and not the DTSTART.

Setting it to the currenct date/time is also no clean option, as in the future 
this will be interpreted as if work on the task is not allowed/started before 
that date/time.

> Should we relax this rule ?

Unless I'm missing something in rfc2445bis that requires DTSTART when DUE is 
present, I suppose that would be possible.
I'm just wondering where that requirement actually comes from and what are the 
reasons behind it.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, [email-masked], http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org