Subject: [ietf-calsify] zero-time events in rfc2445bis

From: Reinhold Kainhofer <[email-masked]>
Date: Tue, 27 Jan 2009 14:54:39 +0100

Hi all,
In RFC2445bis, is it possible to have zero-time events or not? In particular, 
the section "3.8.2.2.  Date/Time End" says that the DTEND MUST be later in 
time than the DTSTART, so zero-time events are not possible using DTEND.

On the other side, "3.6.1.  Event Component" says: 
"For cases where a "VEVENT" calendar component
      specifies a "DTSTART" property with a DATE value type but no
      "DTEND" nor "DURATION" property, the event's duration is taken to
      be one day.  For cases where a "VEVENT" calendar component
      specifies a "DTSTART" property with a DATE-TIME value type but no
      "DTEND" property, the event ends on the same calendar date and
      time of day specified by the "DTSTART" property."

So, it seems that to get a zero-time event, one MUST leave out the DTEND and 
the event must have a time assigned. For events with DTSTART being a DATE-TIME 
the default length is zero, while for events with DTSTART being a DATE the 
default length is one whole day. Isn't this inconsistent?

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
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Jan 2009 15:26:14 +0100

Chair hat on.

While I'm perfectly happy for someone to answer this question, we are 
not entertaining changes to RFC2445bis outside the scope of those 
required to clear IESG DISCUSS comments.

Eliot

On 1/27/09 2:54 PM, Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>   * Financial&  Actuarial Math., Vienna Univ. of Technology, Austria
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFJfxIgTqjEwhXvPN0RAoCyAKCtGvDpdK8TUu6PioPvcEW4bGCs1QCcCvdM
> zUrz91Vr6J3VhCx5CeJJ4Ks=
> =21hP
> -----END PGP SIGNATURE-----

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 27 Jan 2009 09:47:10 -0500

Hi Reinhold,

As it stands I don't believe there is any restriction on zero-time events.

If DTSTART is DATE-TIME value you can either omit DTEND, or set DURATION 
to zero (e.g., "P0S").

If DTSTART is a DATE value you can set DURATION to zero (e.g., "P0D").

That being said, I don't know why RFC2445 had a restriction on DTEND 
being required to be later in time than DTSTART...

Cheers,
Bernard

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 27 Jan 2009 09:53:56 -0500

Hi Bernard,

> being required to be later in time than DTSTART...

If DTSTART == DTEND how would you deal with the fact that DTSTART is 
inclusive but DTEND is exclusive? That would represent a contradiction. It 
could result in different behavior depending on the order of clauses in 
your "if" statement for seeing whether an event intersects a specified 
time-range.

So I think it is always better to say DTEND > DTSTART, if DTEND exists. 
That avoids the possibility of any error.

-- 
Cyrus Daboo

---

From: Reinhold Kainhofer <[email-masked]>
Date: Tue, 27 Jan 2009 16:20:07 +0100

Am Dienstag, 27. Januar 2009 15:53:56 schrieb Cyrus Daboo:
> inclusive but DTEND is exclusive? That would represent a contradiction.

No, that's the exact definition of a zero-time event: Even the starting second 
is not part of the event.
That's useful for e.g. marking certain times (e.g. a deadline for something; a 
deadline is just one particularly marked time and does not take up any time).

> It

But what about the cases with DURATION set to P0S? Aren't they exactly the 
same case?

- --

---

From: Harrie Hazewinkel <[email-masked]>
Date: Tue, 27 Jan 2009 16:41:44 +0100

> deadline is just one particularly marked time and does not take up  

How about using a VTODO? In there you have a 'DUE' property which is
sort of a deadline equivalent.

Although, I believe you want your events in calendars that do not  
support
this VTODO element, but you have ONLY the VEVENT. If so you have the  
'problem'.

Harrie

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 27 Jan 2009 14:33:51 -0500

Since DTSTART with DURATION of 0 works, I suggest that it should be
"standardized" for implementations which require marking events in this
case. I would think that it's a small change for any implentation to switch
from creating iCalendar objects with DTSTART == DTEND for zero-time events
to DTSTART with DURATION = 0.  I don't think it resolves any IESG DISCUSS
issues, so I'm not going to suggest text changes to RFC2445 to require it to
be done that way (but that _would_ simplify things and improve interop) 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Tuesday, January 27, 2009 10:20 AM
To: Cyrus Daboo
Cc: CALSIFY Mailinglist
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

> inclusive but DTEND is exclusive? That would represent a contradiction.

No, that's the exact definition of a zero-time event: Even the starting
second is not part of the event.
That's useful for e.g. marking certain times (e.g. a deadline for something;
a deadline is just one particularly marked time and does not take up any
time).

> It
> could result in different behavior depending on the order of clauses 
> in your "if" statement for seeing whether an event intersects a 
> specified time-range.

- --
 * LilyPond, Music typesetting, http://www.lilypond.org -----BEGIN PGP
SIGNATURE-----

iD8DBQFJfyYnTqjEwhXvPN0RAp+dAJ9GsbsJAaemtYThRgbtw4E9or9TrwCfdIQg
Nw7Li8sKg+o3Fnt0bfkhaUU=
=/5PJ
-----END PGP SIGNATURE-----

From: "Tim Hare" <[email-masked]>
To: "'Reinhold Kainhofer'" <[email-masked]>, "'Cyrus Daboo'" <[email-masked]>
Date: Tue, 27 Jan 2009 14:33:51 -0500
Cc: 'CALSIFY Mailinglist' <[email-masked]>
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

Since DTSTART with DURATION of 0 works, I suggest that it should be
"standardized" for implementations which require marking events in this
case. I would think that it's a small change for any implentation to switch
from creating iCalendar objects with DTSTART == DTEND for zero-time events
to DTSTART with DURATION = 0.  I don't think it resolves any IESG DISCUSS
issues, so I'm not going to suggest text changes to RFC2445 to require it to
be done that way (but that _would_ simplify things and improve interop) 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Tuesday, January 27, 2009 10:20 AM
To: Cyrus Daboo
Cc: CALSIFY Mailinglist
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

> inclusive but DTEND is exclusive? That would represent a contradiction.

No, that's the exact definition of a zero-time event: Even the starting
second is not part of the event.
That's useful for e.g. marking certain times (e.g. a deadline for something;
a deadline is just one particularly marked time and does not take up any
time).

> It
> could result in different behavior depending on the order of clauses 
> in your "if" statement for seeing whether an event intersects a 
> specified time-range.

- --
 * LilyPond, Music typesetting, http://www.lilypond.org -----BEGIN PGP
SIGNATURE-----

iD8DBQFJfyYnTqjEwhXvPN0RAp+dAJ9GsbsJAaemtYThRgbtw4E9or9TrwCfdIQg
Nw7Li8sKg+o3Fnt0bfkhaUU=
=/5PJ
-----END PGP SIGNATURE-----

From: Harrie Hazewinkel <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Date: Tue, 27 Jan 2009 16:41:44 +0100
Cc: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

Harrie

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Cyrus Daboo <[email-masked]>
Date: Tue, 27 Jan 2009 16:20:07 +0100
Cc: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

- -- 

Date: Tue, 27 Jan 2009 09:53:56 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Reinhold Kainhofer <[email-masked]>
Cc: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

Hi Bernard,

-- 
Cyrus Daboo

Date: Tue, 27 Jan 2009 09:47:10 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Cc: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

Hi Reinhold,

Cheers,
Bernard

> default length is one whole day. Isn't this inconsistent?

Date: Tue, 27 Jan 2009 15:26:14 +0100
From: Eliot Lear <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Cc: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [ietf-calsify] zero-time events in rfc2445bis

Chair hat on.

Eliot

> default length is one whole day. Isn't this inconsistent?

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Date: Tue, 27 Jan 2009 14:54:39 +0100
Subject: [ietf-calsify] zero-time events in rfc2445bis

Hi all,

Cheers,
Reinhold
- -- 

From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Date: Sun, 25 Jan 2009 13:24:46 +0100
Subject: [ietf-calsify] iCal event invitation: IETF Calsify Jabber Session

--Apple-Mail-3--971467889
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Eliot Lear has invited you to the iCal event: IETF Calsify Jabber  
Session, scheduled for February 13, 2009 at 2:00 PM (Europe/Dublin).  
To accept or decline this invitation, click the link below.
--Apple-Mail-3--971467889
Content-Type: multipart/mixed;
	boundary=Apple-Mail-4--971467889

--Apple-Mail-4--971467889
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Eliot Lear has invited you to the iCal event: IETF Calsify Jabber Session, scheduled for February 13, 2009 at 2:00 PM (Europe/Dublin). To accept or decline this invitation, click the link below.</font></div></div></body></html>
--Apple-Mail-4--971467889
Content-Disposition: attachment;
	filename=iCal-20090125-122444.ics
Content-Type: text/calendar;
	x-unix-mode=0644;
	name="iCal-20090125-122444.ics"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Inc.//iCal=203.0//EN=0D=0A=
CALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0AMETHOD:REQUEST=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:Europe/Dublin=0D=0ABEGIN:DAYLIGHT=0D=0A=
TZOFFSETFROM:+0000=0D=0ATZOFFSETTO:+0100=0D=0ADTSTART:19810329T010000=0D=0A=
RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D-1SU=0D=0ATZNAME:IST=0D=0A=
END:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0ATZOFFSETFROM:+0100=0D=0A=
TZOFFSETTO:+0000=0D=0ADTSTART:19961027T020000=0D=0A=
RRULE:FREQ=3DYEARLY;BYMONTH=3D10;BYDAY=3D-1SU=0D=0ATZNAME:GMT=0D=0A=
END:STANDARD=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0ASEQUENCE:4=0D=0A=
DTSTART;TZID=3DEurope/Dublin:20090213T140000=0D=0A=
UID:9307BD9E-61E5-4D21-AF9B-3A58F5206C12=0D=0AORGANIZER;CN=3D"Eliot=20=
Lear":mailto:[email-masked]=0D=0ADTSTAMP:20090125T122428Z=0D=0A=
SUMMARY:IETF=20Calsify=20Jabber=20Session=0D=0AATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTIO=0D=0A=20=
N;ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:mailto:[email-masked]=
=0D=0AATTENDEE;CN=3D"Eliot=20=
Lear";PARTSTAT=3DACCEPTED:mailto:[email-masked]=0D=0A=
CREATED:20090125T122346Z=0D=0ADTEND;TZID=3DEurope/Dublin:20090213T150000=0D=
=0ALOCATION:jabber.ietf.org/calsify=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=
=0A=

--Apple-Mail-4--971467889
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "></div></div></body></html>
--Apple-Mail-4--971467889--

--Apple-Mail-3--971467889--

From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Date: Sun, 25 Jan 2009 13:23:29 +0100
Subject: [ietf-calsify] iCal event invitation: IETF Calsify Jabber Session

--Apple-Mail-1--971544472
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Eliot Lear has invited you to the iCal event: IETF Calsify Jabber  
Session, scheduled for February 11, 2009 at 3:00 PM (Europe/Dublin).  
To accept or decline this invitation, click the link below.
--Apple-Mail-1--971544472
Content-Type: multipart/mixed;
	boundary=Apple-Mail-2--971544470

--Apple-Mail-2--971544470
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Eliot Lear has invited you to the iCal event: IETF Calsify Jabber Session, scheduled for February 11, 2009 at 3:00 PM (Europe/Dublin). To accept or decline this invitation, click the link below.</font></div></div></body></html>
--Apple-Mail-2--971544470
Content-Disposition: attachment;
	filename=iCal-20090125-122302.ics
Content-Type: text/calendar;
	x-unix-mode=0644;
	name="iCal-20090125-122302.ics"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Inc.//iCal=203.0//EN=0D=0A=
CALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0AMETHOD:REQUEST=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:Europe/Dublin=0D=0ABEGIN:DAYLIGHT=0D=0A=
TZOFFSETFROM:+0000=0D=0ATZOFFSETTO:+0100=0D=0ADTSTART:19810329T010000=0D=0A=
RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D-1SU=0D=0ATZNAME:IST=0D=0A=
END:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0ATZOFFSETFROM:+0100=0D=0A=
TZOFFSETTO:+0000=0D=0ADTSTART:19961027T020000=0D=0A=
RRULE:FREQ=3DYEARLY;BYMONTH=3D10;BYDAY=3D-1SU=0D=0ATZNAME:GMT=0D=0A=
END:STANDARD=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0ASEQUENCE:5=0D=0A=
DTSTART;TZID=3DEurope/Dublin:20090211T150000=0D=0A=
UID:F159606F-C22A-4C60-A4B2-B3BC45621FD1=0D=0AORGANIZER;CN=3D"Eliot=20=
Lear":mailto:[email-masked]=0D=0ADTSTAMP:20090125T122242Z=0D=0A=
SUMMARY:IETF=20Calsify=20Jabber=20Session=0D=0AATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTIO=0D=0A=20=
N;ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:mailto:[email-masked]=
=0D=0AATTENDEE;CN=3D"Eliot=20=
Lear";PARTSTAT=3DACCEPTED:mailto:[email-masked]=0D=0A=
CREATED:20090125T122147Z=0D=0ADTEND;TZID=3DEurope/Dublin:20090211T160000=0D=
=0ALOCATION:jabber.ietf.org/calsify=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=
=0A=

--Apple-Mail-2--971544470
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "></div></div></body></html>
--Apple-Mail-2--971544470--

--Apple-Mail-1--971544472--

Date: Sun, 25 Jan 2009 08:29:46 +0100
From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: [ietf-calsify] Two Jabber Sessions scheduled for 2446bis

Dear all,

Thanks for your participation in the doodle poll.  To move us forward, 
here are two jabber sessions.

Wed. Feb 11, 2009, 3:00PM GMT
Fri, Feb 13, 2009, 2:00PM GMT

Each session will run one hour.  The agenda will be to go through open 
issues and to schedule follow-up jabber sessions.  All decisions are 
finalized on this mailing list, per IETF rules.

Eliot

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Date: Fri, 23 Jan 2009 22:15:26 +0100
Cc: Arnaud Quillaud <[email-masked]>
Subject: Re: [ietf-calsify] Disconnect between icalendar and iTIP mandatory properties

Am Donnerstag, 22. Januar 2009 17:27:06 schrieb Arnaud Quillaud:
> For VTODO, the DTSTART, PRIORITY and SUMMARY are mandatory in iTIP
> 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... 

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

I totally agree.

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

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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Date: Fri, 23 Jan 2009 22:15:14 +0100
Subject: Re: [ietf-calsify] Question about interaction between DTSTART and BYSETPOS

Am Donnerstag, 22. Januar 2009 20:44:55 schrieb Rick DeNatale:
> The 3rd instance into the month of one of Tuesday, Wednesday or Thursday,
> for the next 3 months:
>
>   DTSTART;TZID=US-Eastern:19970904T090000
>
>   RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
>   ==> (1997 9:00 AM EDT)September 4;October 7
>          (1997 9:00 AM EST)November 6
>
> As I understand things, the recurrence set consists of the occurrence
> specified by DTSTART (regardless whether or not that time meets the other
> criteria) and then any following times which meet the critera.  My basic
> approach follows this, after producing the DTSTART occurence, I get the
> next occurrence by incrementing the time based on the BYXXX and FREQ parts,
> and never consider times prior to DTSTART.
>
> I also think that the 'set' implied by BYSETPOS, is the set of occurrences
> meeting the other criteria within one increment of the FREQ value.

Exactly.

> For example, what should be produced if the DTSTART were 19970901?  I'd
> guess September 1, September 4 and October 7.

That's invalid iCalendar according to rfc2445bis, where DTSTART has to match 
the RRULE.

> And what if it were 19970905?  I guess in this case it would be September
> 5, October 7, and November 6.

Nope, the DTSTART has to match the rule in rfc2445bis. Sept 5 does not match 
the RRULE, so that would no longer be a valid iCalendar object.

However, if you relax the new requirement that DTSTART has to match RRULE, 
then yes, your results are correct in both cases.

> I'm thinking that in the case of having BYSETPOS, I need to start examining
> candidates at the beginning of the FREQ period containing DTSTART in order
> to compute the first set, and discard any occurrences prior to DTSTART,
> while ensuring that the DTSTART is included.
>
> Does this sound right?

Yes, exactly. In rfc2445bis, we also included a requirement that the DTSTART 
has to match the RRULE, so you definitely have to look at the whole month, 
irrespective of whether the DTSTART is some date within the month already.

Cheers,
Reinhold

- -- 

Date: Fri, 23 Jan 2009 09:46:12 -0500
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: Calsify <[email-masked]>
Subject: Re: [ietf-calsify] iTIP open issues

Hi Eliot,

--On January 23, 2009 3:15:35 PM +0100 Eliot Lear <[email-masked]> wrote:

> Ok, let's try one more time.  Only two people doodled the schedule
> proposals, probably because of CalConnect.  We will push one week out.
> If we fail to doodle again, then the chairs are going to have to take
> more serious action in consideration of these drafts.  That may require a
> meeting in SF.  I would like to avoid that.

My availability added.

-- 
Cyrus Daboo

Date: Fri, 23 Jan 2009 15:18:14 +0100
From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: [ietf-calsify] Jabber Session for Open 2446 issues

Dear all,

Please go to the following link now and choose times that are convenient 
for you to participate in a Jabber session.

http://www.doodle.com/participation.html?pollId=e2uvzzf3per72ae9

If you have previously voted, *PLEASE DO SO AGAIN.

*Thank you,

Eliot

Date: Fri, 23 Jan 2009 15:15:35 +0100
From: Eliot Lear <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: Calsify <[email-masked]>
Subject: Re: [ietf-calsify] iTIP open issues

Ok, let's try one more time.  Only two people doodled the schedule 
proposals, probably because of CalConnect.  We will push one week out.  
If we fail to doodle again, then the chairs are going to have to take 
more serious action in consideration of these drafts.  That may require 
a meeting in SF.  I would like to avoid that.

Eliot

On 1/19/09 3:35 PM, Eliot Lear wrote:
> Thanks for that, Cyrus.  What I would like to do is schedule a jabber
> meeting in about two week's time.  To do so, and so that it is
> convenient for as many people as possible, can everyone please take a
> moment and go to the following web page:
>
> http://www.doodle.com/participation.html?pollId=e2uvzzf3per72ae9
>
> I'll look at results in the next two days to schedule.
>
> Eliot
>
> On 1/19/09 4:25 AM, Cyrus Daboo wrote:
>    
>> Hi folks,
>> Here are the list of currently open issues from Reinhold's review:
>>
>> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Review_RFC2446bis_2008-09.pdf>
>>
>> Issues: #25, #30, #33, #40, #59, #64, #67, #70, #95, #105, #106, #107, #109.
>>
>> These issues need further discussion.
>>
>> Other issues have been dealt with (either fixed or not) as per
>> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issues.pdf>.
>> All of this needs review from other people to confirm that the changes made
>> (or not made) are valid.
>>
>>
>>      
>

Date: Fri, 23 Jan 2009 09:05:22 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Arnaud Quillaud <[email-masked]>, [email-masked]
Subject: Re: [ietf-calsify] Disconnect between icalendar and iTIP mandatory properties

Hi Cyrus,

Cyrus Daboo wrote:
> Hi Arnaud,
> 
> --On January 22, 2009 5:27:06 PM +0100 Arnaud Quillaud 
> <[email-masked]> wrote:
> 
>> 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 ?
> 
> 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

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

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

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

Date: Thu, 22 Jan 2009 14:44:55 -0500
From: Rick DeNatale <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] Question about interaction between DTSTART and BYSETPOS

--0016361e8880bebaa004611781da
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This is my first posting to this list. I hope it's not off base.

I've been working on a new Ruby library to implement RFC 2445.

I've got most of the examples of recurrence rules working, but I'm not sure
I understand the next to last example on p 124:

The 3rd instance into the month of one of Tuesday, Wednesday or Thursday,
for the next 3 months:

  DTSTART;TZID=US-Eastern:19970904T090000

  RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
  ==> (1997 9:00 AM EDT)September 4;October 7
         (1997 9:00 AM EST)November 6

As I understand things, the recurrence set consists of the occurrence
specified by DTSTART (regardless whether or not that time meets the other
criteria) and then any following times which meet the critera.  My basic
approach follows this, after producing the DTSTART occurence, I get the next
occurrence by incrementing the time based on the BYXXX and FREQ parts, and
never consider times prior to DTSTART.

I also think that the 'set' implied by BYSETPOS, is the set of occurrences
meeting the other criteria within one increment of the FREQ value.

So right now my code is including September 10 as well. It examines:

   Sept 4 - accepted because it's DTSTART - I'm counting this as the first
member of the set.
   Sept 5, 7, 8 - rejected because they are not TU, WE, or TH
   Sept 9 - The second member of the set - rejected because it's not the
third member
   Sept 10 - The third member of the set

And as a result I produce
==> (1997 9:00 AM EDT)September 4;September 10;October 7

My question is how to adjust my model here. Since there don't seem to be
many examples of BYSETPOS, I'm not sure how to extrapolate,  Part of my
problem is that September 4 1997 just happens to be the third instance of
TU, WE, or TH in September 1997, what if it weren't?

For example, what should be produced if the DTSTART were 19970901?  I'd
guess September 1, September 4 and October 7.

And what if it were 19970905?  I guess in this case it would be September 5,
October 7, and November 6.

I'm thinking that in the case of having BYSETPOS, I need to start examining
candidates at the beginning of the FREQ period containing DTSTART in order
to compute the first set, and discard any occurrences prior to DTSTART,
while ensuring that the DTSTART is included.

Does this sound right?

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

--0016361e8880bebaa004611781da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is my first posting to this list. I hope it&#39;s not off base.<br><br=
>I&#39;ve been working on a new Ruby library to implement RFC 2445.<br><br>=
I&#39;ve got most of the examples of recurrence rules working, but I&#39;m =
not sure I understand the next to last example on p 124:<br>
<br>The 3rd instance into the month of one of Tuesday, Wednesday or Thursda=
y, for the next 3 months:<br><br>&nbsp; DTSTART;TZID=3DUS-Eastern:19970904T=
090000<br><br>&nbsp; RRULE:FREQ=3DMONTHLY;COUNT=3D3;BYDAY=3DTU,WE,TH;BYSETP=
OS=3D3<br>&nbsp; =3D=3D&gt; (1997 9:00 AM EDT)September 4;October 7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1997 9:00 AM EST)November=
 6<br><br>As I understand things, the recurrence set consists of the occurr=
ence specified by DTSTART (regardless whether or not that time meets the ot=
her criteria) and then any following times which meet the critera.&nbsp; My=
 basic approach follows this, after producing the DTSTART occurence, I get =
the next occurrence by incrementing the time based on the BYXXX and FREQ pa=
rts, and never consider times prior to DTSTART.<br>
<br>I also think that the &#39;set&#39; implied by BYSETPOS, is the set of =
occurrences meeting the other criteria within one increment of the FREQ val=
ue.<br><br>So right now my code is including September 10 as well. It exami=
nes:<br>
<br>&nbsp;&nbsp; Sept 4 - accepted because it&#39;s DTSTART - I&#39;m count=
ing this as the first member of the set.<br>&nbsp;&nbsp; Sept 5, 7, 8 - rej=
ected because they are not TU, WE, or TH<br>&nbsp;&nbsp; Sept 9 - The secon=
d member of the set - rejected because it&#39;s not the third member<br>
&nbsp;&nbsp; Sept 10 - The third member of the set<br><br>And as a result I=
 produce<br> =3D=3D&gt; (1997 9:00 AM EDT)September 4;September 10;October =
7<br>
<br clear=3D"all">My question is how to adjust my model here. Since there d=
on&#39;t seem to be many examples of BYSETPOS, I&#39;m not sure how to extr=
apolate,&nbsp; Part of my problem is that September 4 1997 just happens to =
be the third instance of TU, WE, or TH in September 1997, what if it weren&=
#39;t?<br>
<br>For example, what should be produced if the DTSTART were 19970901?&nbsp=
; I&#39;d guess September 1, September 4 and October 7.<br><br>And what if =
it were 19970905?&nbsp; I guess in this case it would be September 5, Octob=
er 7, and November 6.<br>
<br>I&#39;m thinking that in the case of having BYSETPOS, I need to start e=
xamining candidates at the beginning of the FREQ period containing DTSTART =
in order to compute the first set, and discard any occurrences prior to DTS=
TART, while ensuring that the DTSTART is included.<br>
<br>Does this sound right?<br><br>-- <br>Rick DeNatale<br><br>Blog: <a href=
=3D"http://talklikeaduck.denhaven2.com/">http://talklikeaduck.denhaven2.com=
/</a><br>Twitter: <a href=3D"http://twitter.com/RickDeNatale">http://twitte=
r.com/RickDeNatale</a><br>

--0016361e8880bebaa004611781da--

Date: Thu, 22 Jan 2009 10:11:11 -0800 (PST)
From: Anil SRIVASTAVA <[email-masked]>
Sender: [email-masked]
To: Arnaud Quillaud <[email-masked]>
Organization: Sun Microsystems [http://www.sun.com]
Accept-Language: English; en
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-calsify] Disconnect between icalendar and iTIP mandatory properties
Reply-To: [email-masked]

On 2009-01-22/17:27 [+0100], [email-masked] [Arnaud Quillaud] wrote:

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

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

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

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

Date: Thu, 22 Jan 2009 12:30:29 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, [email-masked]
Subject: Re: [ietf-calsify] Disconnect between icalendar and iTIP mandatory	properties

Hi Arnaud,

--On January 22, 2009 5:27:06 PM +0100 Arnaud Quillaud 
<[email-masked]> wrote:

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

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.

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

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

Date: Thu, 22 Jan 2009 17:27:06 +0100
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: [ietf-calsify] Disconnect between icalendar and iTIP mandatory properties

Hello,

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.

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Date: Tue, 20 Jan 2009 00:55:35 +0100
Subject: Re: [ietf-calsify] iTIP open issues

Am Montag, 19. Januar 2009 04:25:39 schrieb Cyrus Daboo:
> Other issues have been dealt with (either fixed or not) as per
> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issu
>es.pdf>. All of this needs review from other people to confirm that the
> changes made (or not made) are valid.

I took a look at the issues you marked as fixed in your table. Mostly, the 
changes fix my issues. However:

#25: Maybe it should be mentioned that the uninvited CU replies to the 
"Organizer" adding himself as an ATTENDEE? (It might be clear from the 
definition of a REPLY, but in the table in section 3.2.3 we say "MUST be the 
address of the Attendee replying". The uninvited CU is not an attendee, 
though...)

#36: I would also add the usual "MUST be present if any date/time refers to a 
timezone" comment for VTIMEZONE, which is present in all other tables.

#60: You say that "unsuccessfull" is only meant for technical failures, not 
for requests that are declined and are unsuccessfull requests in that sense. 
The word "method" in "to an unsuccessfull VTODO calendar component REQUEST 
method" might be enough to indicate this, but it would still be be a good idea 
to make it clear that unsuccessfull is meant as a technical failure.

#65: DTSTART, DUE and RDATE can have different time zones attached, in which 
case "0 or 1" for VTIMEZONE is not sufficient. I would suggest "0+". The same 
goes for 3.4.7 COUNTER.

#78: The last sentence "is used as the value "RECURRENCE-ID" property" is 
missing an "of the".

#92: Some FREEBUSY properties are still outside the 1.1.-8.1. time frame 
specified by DTSTART and DTEND

Nitpicking: 
- -) I also noticed that section 4.2.3 is named "Update An Event", while other 
sections use "an" in lowercase.
- -) Similarly, sections 4.1.2, 4.1.3, 4.2.2, 4.2.9, 4.4.6, 4.4.7, 4.4.8, 4.4.9 
use "A" in uppercase (6.1.5 in lowercase).
- -) Sections 4.1.5, 6.2.1, A.2 do not use headline uppercasing at all.
- -) Sections 3.2, 4.5.3 use "for", Sections 3.3, 3.4, 3.5 use "For".

Cheers,
Reinhold
- -- 

From: "Tim Hare" <[email-masked]>
To: "'Reinhold Kainhofer'" <[email-masked]>, <[email-masked]>
Date: Mon, 19 Jan 2009 17:02:35 -0500
Subject: Re: [ietf-calsify] iTIP open issues

I do not want to make an incompatible change - and I overlooked that.  

I guess this should be filed under "proposals for how iCalendar should have
been designed better" and forgotten.

As for GUI issues - I would say if an alarm changes in someones CUA it would
become a different alarm with a different alarmid - the CUA SHOULD scan for
duplicates before creating a new one. In practice I believe the number of
alarms to be fairly small, and burden to select VALARMS used by VEVENTS or
VTODOs would of course depend upon the implementation of the calendar store.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Monday, January 19, 2009 1:33 PM
To: [email-masked]
Cc: Tim Hare; 'Cyrus Daboo'
Subject: Re: [ietf-calsify] iTIP open issues

Am Montag, 19. Januar 2009 schrieb Tim Hare:
> It might be useful to make VALARM a component at the same level as 
> VTIMEZONE, so that other entries in a calendar stream could refer to them.

There are advantages and disadvantages to this:
- -) It is an incompatible change!
+) alarm components can be reused
+) One less occurrence of nested objects
- -) Like with VTIMEZONE, you can no longer sequentially write out one
VEVENT/VTODO/VJOURNAL after the other, but first have to scan for used
VALARM objects, which have to be printed out separately (first?).
Alternatively, you need to build the whole output structure in memory before
writing it to file.
- -) Possible ambiguities in the GUI: Several VEVENT components can have the
same VALARM assigned. If you change the alarm of one of these events, shall
the "other" alarms be automatically changed, too? From a user's perspective,
this would be VERY confusing at best. 

> Another advantage would be elimination of a BEGIN:/END: sequence 
> within another BEGIN:/END: component sequence, which may or may not be 
> a parsing issue for some. I think VALARM is the only component (or 
> perhaps we should say component-like property) which currently can be 
> contained within another component.

A VTIMEZONE component also contains DAYLIGHT and STANDARD components... So a
parser must be able top handle them properly

> Some proposed text/ideas for changes in 2445
>
> -----------------------------------
> In 3.6.6
>
> Add alarmid as a property of a VALARM component.
>
> Alarmid is REQUIRED, but MUST NOT occur more than once

This is an incompatible change and would make all previous iCalendar files
using VALARM invalid (and all new ones invalid with regard to the old
definition), so in this case the VERSION property should also be increased
to 3.0, which I don't think we want to / should do...

Cheers,
Reinhold
- --
 * LilyPond, Music typesetting, http://www.lilypond.org -----BEGIN PGP
SIGNATURE-----

iD4DBQFJdMdBTqjEwhXvPN0RAnzsAJ9hEv6az35SueTuuvmIrwF5cDnupACXUXq/
Uzxd8K8SGCsNNJALPfoEYw==
=vPei
-----END PGP SIGNATURE-----

Date: Mon, 19 Jan 2009 11:01:49 -0800 (PST)
From: Adrian Crum <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-calsify] iTIP open issues
Reply-To: [email-masked]

--- On Mon, 1/19/09, Reinhold Kainhofer <[email-masked]> wrote:
> > Some proposed text/ideas for changes in 2445
> >
> > -----------------------------------
> > In 3.6.6
> >
> > Add alarmid as a property of a VALARM component.
> >
> > Alarmid is REQUIRED, but MUST NOT occur more than once
>
> This is an incompatible change and would make all previous
> iCalendar files
> using VALARM invalid (and all new ones invalid with regard
> to the old
> definition), so in this case the VERSION property should
> also be increased to
> 3.0, which I don't think we want to / should do...

There are many things in the draft that are incompatible with the existing standard. Why not add one more?

-Adrian

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Date: Mon, 19 Jan 2009 19:32:32 +0100
Subject: Re: [ietf-calsify] iTIP open issues

Am Montag, 19. Januar 2009 schrieb Tim Hare:
> It might be useful to make VALARM a component at the same level as
> VTIMEZONE, so that other entries in a calendar stream could refer to them.

There are advantages and disadvantages to this:
- -) It is an incompatible change!
+) alarm components can be reused
+) One less occurrence of nested objects
- -) Like with VTIMEZONE, you can no longer sequentially write out one 
VEVENT/VTODO/VJOURNAL after the other, but first have to scan for used VALARM 
objects, which have to be printed out separately (first?). Alternatively, you 
need to build the whole output structure in memory before writing it to file.
- -) Possible ambiguities in the GUI: Several VEVENT components can have the 
same VALARM assigned. If you change the alarm of one of these events, shall 
the "other" alarms be automatically changed, too? From a user's perspective, 
this would be VERY confusing at best. 

> Another advantage would be elimination of a BEGIN:/END: sequence within
> another BEGIN:/END: component sequence, which may or may not be a parsing
> issue for some. I think VALARM is the only component (or perhaps we should
> say component-like property) which currently can be contained within
> another component.

A VTIMEZONE component also contains DAYLIGHT and STANDARD components... So a 
parser must be able top handle them properly

> Some proposed text/ideas for changes in 2445
>
> -----------------------------------
> In 3.6.6
>
> Add alarmid as a property of a VALARM component.
>
> Alarmid is REQUIRED, but MUST NOT occur more than once

This is an incompatible change and would make all previous iCalendar files 
using VALARM invalid (and all new ones invalid with regard to the old 
definition), so in this case the VERSION property should also be increased to 
3.0, which I don't think we want to / should do...

Cheers,
Reinhold
- -- 

From: "Tim Hare" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>, "'Calsify'" <[email-masked]>
Date: Mon, 19 Jan 2009 11:58:25 -0500
Subject: Re: [ietf-calsify] iTIP open issues

Small comment on a small issue:  VALARM at the same level as other
components (really a 2445 issue?)

It might be useful to make VALARM a component at the same level as
VTIMEZONE, so that other entries in a calendar stream could refer to them.
This would be purely to shorten the serialized data.  Many CUAs have a
default for "reminder" (say, 15 minutes before the event, make a chime noise
and display something) - having VALARM at the component level would allow
defining it once and referring to it.

Another advantage would be elimination of a BEGIN:/END: sequence within
another BEGIN:/END: component sequence, which may or may not be a parsing
issue for some. I think VALARM is the only component (or perhaps we should
say component-like property) which currently can be contained within another
component.

Some proposed text/ideas for changes in 2445

-----------------------------------
In 3.6.6 

Add alarmid as a property of a VALARM component.  

Alarmid is REQUIRED, but MUST NOT occur more than once

Remove the requirement for TRIGGER and the paragraphs about TRIGGER

In 3.6.1 and 3.6.2

Remove *alarmc and add a property named alarm which is OPTIONAL and MAY
occur more than ocne

Add ALARM as a property to the text.

ALARM ALARMID=,RELATED=:  

Where the ALARMID is a reference to the VALARM component, RELATED and the
ALARM value work like TRIGGER worked in VALARM

--------------------------------------------

I will try to work out better text for this, but I wanted to put the idea
out there.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Sunday, January 18, 2009 10:26 PM
To: Calsify
Subject: [ietf-calsify] iTIP open issues

Hi folks,
Here are the list of currently open issues from Reinhold's review:

<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Revie
w_RFC2446bis_2008-09.pdf>

Issues: #25, #30, #33, #40, #59, #64, #67, #70, #95, #105, #106, #107, #109.

These issues need further discussion.

Other issues have been dealt with (either fixed or not) as per
<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issue
s.pdf>. 
All of this needs review from other people to confirm that the changes made
(or not made) are valid.

--
Cyrus Daboo

Date: Mon, 19 Jan 2009 09:42:41 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: Calsify <[email-masked]>
Subject: Re: [ietf-calsify] iTIP open issues

Hi Eliot,

This specific week conflicts with CalConnect XIV.

Cheers,
Bernard

Eliot Lear wrote:
> Thanks for that, Cyrus.  What I would like to do is schedule a jabber 
> meeting in about two week's time.  To do so, and so that it is 
> convenient for as many people as possible, can everyone please take a 
> moment and go to the following web page:
>
> http://www.doodle.com/participation.html?pollId=e2uvzzf3per72ae9
>
> I'll look at results in the next two days to schedule.
>
> Eliot
>
> On 1/19/09 4:25 AM, Cyrus Daboo wrote:
>   
>> Hi folks,
>> Here are the list of currently open issues from Reinhold's review:
>>
>> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Review_RFC2446bis_2008-09.pdf>
>>
>> Issues: #25, #30, #33, #40, #59, #64, #67, #70, #95, #105, #106, #107, #109.
>>
>> These issues need further discussion.
>>
>> Other issues have been dealt with (either fixed or not) as per
>> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issues.pdf>.
>> All of this needs review from other people to confirm that the changes made
>> (or not made) are valid.
>>
>>    
>>     
>

Date: Mon, 19 Jan 2009 15:35:43 +0100
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Calsify <[email-masked]>
Subject: Re: [ietf-calsify] iTIP open issues

Thanks for that, Cyrus.  What I would like to do is schedule a jabber 
meeting in about two week's time.  To do so, and so that it is 
convenient for as many people as possible, can everyone please take a 
moment and go to the following web page:

http://www.doodle.com/participation.html?pollId=e2uvzzf3per72ae9

I'll look at results in the next two days to schedule.

Eliot

On 1/19/09 4:25 AM, Cyrus Daboo wrote:
> Hi folks,
> Here are the list of currently open issues from Reinhold's review:
>
> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Review_RFC2446bis_2008-09.pdf>
>
> Issues: #25, #30, #33, #40, #59, #64, #67, #70, #95, #105, #106, #107, #109.
>
> These issues need further discussion.
>
> Other issues have been dealt with (either fixed or not) as per
> <http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issues.pdf>.
> All of this needs review from other people to confirm that the changes made
> (or not made) are valid.
>
>    

Date: Mon, 19 Jan 2009 09:16:54 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Arnaud Quillaud <[email-masked]>, [email-masked]
Subject: Re: [ietf-calsify] REQUEST-STATUS mandatory only for VTODO REPLY

Hi Cyrus,

Cyrus Daboo wrote:
> Hi Bernard,
>
> --On January 16, 2009 3:33:04 PM -0500 Bernard Desruisseaux 
>> You stung my curiosity! I ran the following egrep command against the
>> draft and found other inconsistencies...
>>
>> egrep "(\|.*REQUEST-STATUS|^   \| METHOD|\| VEVENT.*1+|\|
>> VFREEBUSY.*1+|\| VTODO.*1+|\| VJOURNAL.*1+)"
>> draft-ietf-calsify-2446bis-08.txt
>>
>> In summary (including the issue you found):
>>
>> 1- In VEVENT w/ METHOD:REQUEST -> REQUEST-STATUS should be 0  and not 0+
>> 2- In VEVENT w/ METHOD:COUNTER -> REQUEST-STATUS should be 0  and not 0+
>> 3- In VTODO  w/ METHOD:REPLY   -> REQUEST-STATUS should be 0+ and not 1+
>> 4- In VTODO  w/ METHOD:COUNTER -> REQUEST-STATUS should be 0  and not 0+
>
> I agree with #1 and #3 and have updated my working copy accordingly.
>
> I am not totally convinced about #2 and #3.
I assume you meant #2 and #4 (i.e., METHOD:COUNTER).
> I would like to know why you think that a COUNTER is not a reply to 
> the organizer that can carry status about the original request that it 
> is countering.
>
I couldn't find any text or example in RFC2446 that would suggest that 
COUNTER can be used as a reply to the original REQUEST. On the other 
hand, the text makes it clear that REPLY may be used to respond to an 
unsuccessful request:

% grep -A 2 "respond to an un" rfc2446.txt

   The "REPLY" method may also be used to respond to an unsuccessful
   "REQUEST" method. Depending on the value of the "REQUEST-STATUS"
   property no scheduling action may have been performed.
--
   The "REPLY" method may also be used to respond to an unsuccessful
   "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy
   time information may be returned.
--
   The "REPLY" method MAY also be used to respond to an unsuccessful
   "VTODO" calendar component "REQUEST" method. Depending on the
   "REQUEST-STATUS" value, no scheduling action may have been performed.

Also, as mentioned in the text, "REQUEST-STATUS" is not required in 
successful transactions.

In most (all?) cases, a COUNTER *request* will be initiated by the end 
user when the original REQUEST transaction was successful. If the 
original REQUEST was unsuccessful, what would the end user be countering 
anyway?

Cheers,
Bernard

Date: Sun, 18 Jan 2009 22:33:59 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Arnaud Quillaud <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-calsify] REQUEST-STATUS mandatory only for VTODO REPLY

Hi Bernard,

--On January 16, 2009 3:33:04 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> You stung my curiosity! I ran the following egrep command against the
> draft and found other inconsistencies...
>
> egrep "(\|.*REQUEST-STATUS|^   \| METHOD|\| VEVENT.*1+|\|
> VFREEBUSY.*1+|\| VTODO.*1+|\| VJOURNAL.*1+)"
> draft-ietf-calsify-2446bis-08.txt
>
> In summary (including the issue you found):
>
> 1- In VEVENT w/ METHOD:REQUEST -> REQUEST-STATUS should be 0  and not 0+
> 2- In VEVENT w/ METHOD:COUNTER -> REQUEST-STATUS should be 0  and not 0+
> 3- In VTODO  w/ METHOD:REPLY   -> REQUEST-STATUS should be 0+ and not 1+
> 4- In VTODO  w/ METHOD:COUNTER -> REQUEST-STATUS should be 0  and not 0+

I agree with #1 and #3 and have updated my working copy accordingly.

I am not totally convinced about #2 and #3. I would like to know why you 
think that a COUNTER is not a reply to the organizer that can carry status 
about the original request that it is countering.

-- 
Cyrus Daboo

Date: Sun, 18 Jan 2009 22:25:39 -0500
From: Cyrus Daboo <[email-masked]>
To: Calsify <[email-masked]>
Subject: [ietf-calsify] iTIP open issues

Hi folks,
Here are the list of currently open issues from Reinhold's review:

<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Review_RFC2446bis_2008-09.pdf>

Issues: #25, #30, #33, #40, #59, #64, #67, #70, #95, #105, #106, #107, #109.

These issues need further discussion.

Other issues have been dealt with (either fixed or not) as per 
<http://trac.tools.ietf.org/wg/calsify/trac/attachment/wiki/RFC2446bis/Issues.pdf>. 
All of this needs review from other people to confirm that the changes made 
(or not made) are valid.

-- 
Cyrus Daboo

Date: Fri, 16 Jan 2009 15:46:12 -0500
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, CALSIFY Mailinglist <[email-masked]>
Subject: Re: [ietf-calsify] open issues with 2446/2447

Hi Eliot,

--On January 14, 2009 5:43:19 PM +0100 Eliot Lear <[email-masked]> wrote:

> In considering whether to hold a working group meeting in San Francisco
> to resolve open issues, we would like to understand who would
> participate.  The other possibilities would be to restart our jabber
> sessions or to proceed via email alone.  Could you please take a moment
> to answer then this question:
>
> In which way would you like to participate?
>
> 1.  Meet in San Francisco during the week of the 20th of March
> 2.  Jabber
> 3.  Email alone
>
> Email is always open to participants and all decisions are confirmed via
> email.

My preferences: lets start things off with a phone call, then fall back to 
jabber once a week or every fortnight. I think face-to-face will be hard in 
light of budgetary restrictions for travel.

I will try and get outstanding 2446bis issues enumerated this weekend and 
start posting them to the list to get things going again.

-- 
Cyrus Daboo

Date: Fri, 16 Jan 2009 15:33:04 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-calsify] REQUEST-STATUS mandatory only for VTODO REPLY

Arnaud,

You stung my curiosity! I ran the following egrep command against the 
draft and found other inconsistencies...

egrep "(\|.*REQUEST-STATUS|^   \| METHOD|\| VEVENT.*1+|\| 
VFREEBUSY.*1+|\| VTODO.*1+|\| VJOURNAL.*1+)" 
draft-ietf-calsify-2446bis-08.txt

In summary (including the issue you found):

1- In VEVENT w/ METHOD:REQUEST -> REQUEST-STATUS should be 0  and not 0+
2- In VEVENT w/ METHOD:COUNTER -> REQUEST-STATUS should be 0  and not 0+
3- In VTODO  w/ METHOD:REPLY   -> REQUEST-STATUS should be 0+ and not 1+
4- In VTODO  w/ METHOD:COUNTER -> REQUEST-STATUS should be 0  and not 0+

Cheers,
Bernard

Arnaud Quillaud wrote:
> Is there a particular reason why the REQUEST-STATUS is mandated in a 
> VTODO REPLY 
> (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-08#section-3.4.3) 
> when it is not in a VEVENT REPLY 
> (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-08#section-3.2.3) ?
>
> If there is none, shouldn't we make the REQUEST-STATUS a 0+ also for VTODO ?
>
> Arnaud Q

Date: Fri, 16 Jan 2009 16:19:19 +0100
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: [ietf-calsify] REQUEST-STATUS mandatory only for VTODO REPLY

Is there a particular reason why the REQUEST-STATUS is mandated in a 
VTODO REPLY 
(http://tools.ietf.org/html/draft-ietf-calsify-2446bis-08#section-3.4.3) 
when it is not in a VEVENT REPLY 
(http://tools.ietf.org/html/draft-ietf-calsify-2446bis-08#section-3.2.3) ?

If there is none, shouldn't we make the REQUEST-STATUS a 0+ also for VTODO ?

Arnaud Q

Date: Wed, 14 Jan 2009 17:43:19 +0100
From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: [ietf-calsify] open issues with 2446/2447

Dear all,

In considering whether to hold a working group meeting in San Francisco 
to resolve open issues, we would like to understand who would 
participate.  The other possibilities would be to restart our jabber 
sessions or to proceed via email alone.  Could you please take a moment 
to answer then this question:

In which way would you like to participate?

1.  Meet in San Francisco during the week of the 20th of March
2.  Jabber
3.  Email alone

Email is always open to participants and all decisions are confirmed via 
email.

Thanks for your help,

Eliot