Subject: [Ietf-calsify] Cancel: Weekly Jabber Chat

From: aki.niemi at nokia.com ([email-masked])
Date: Wed Nov 29 00:24:25 2006

After skipping a week due to the US Thanksgiving holiday, let's continue on our weekly Jabber chats again.

Agenda:

- Agenda bash, setting up
- Discussing the remaining open issues with RFC 2445bis.
- AOB

Resources:

Link to the Calsify WG issue tracker:

http://ofcourseimright.com/cgi-bin/roundup/calsify/

A good place to learn more about Jabber is at:

http://www.jabber.org

See you there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20061129/2c6d53a6/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2131 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20061129/2c6d53a6/attachment.icz

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Wed Nov 29 02:10:09 2006

All,

We need to cancel this week's Jabber chat. Turns out we are not able to
get a reasonable attendance this time due to vacations and other
scheduling problems. 

We're still on for next week, though.

Cheers,
Aki

On Wed, 2006-11-29 at 10:23 +0200, ext
[email-masked] wrote:
> After skipping a week due to the US Thanksgiving holiday, let's
> continue on our weekly Jabber chats again.
> 
> Agenda:
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Subject: Re: [Ietf-calsify] Cancel: Weekly Jabber Chat
From: Aki Niemi <[email-masked]>
To: Calsify WG <[email-masked]>
Organization: Nokia-NRC/Helsinki
Date: Wed, 29 Nov 2006 11:27:11 +0200

All,

We need to cancel this week's Jabber chat. Turns out we are not able to
get a reasonable attendance this time due to vacations and other
scheduling problems. 

We're still on for next week, though.

Cheers,
Aki

On Wed, 2006-11-29 at 10:23 +0200, ext
[email-masked] wrote:
> After skipping a week due to the US Thanksgiving holiday, let's
> continue on our weekly Jabber chats again.
> 
> Agenda:
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Content-class: urn:content-classes:calendarmessage
Date: Wed, 29 Nov 2006 10:23:42 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: [Ietf-calsify] Cancel: Weekly Jabber Chat

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7138F.AEF9F58B
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

QWZ0ZXIgc2tpcHBpbmcgYSB3ZWVrIGR1ZSB0byB0aGUgVVMgVGhhbmtzZ2l2aW5nIGhvbGlkYXks
IGxldCdzIGNvbnRpbnVlIG9uIG91ciB3ZWVrbHkgSmFiYmVyIGNoYXRzIGFnYWluLg0KDQpBZ2Vu
ZGE6DQoNCi0gQWdlbmRhIGJhc2gsIHNldHRpbmcgdXANCi0gRGlzY3Vzc2luZyB0aGUgcmVtYWlu
aW5nIG9wZW4gaXNzdWVzIHdpdGggUkZDIDI0NDViaXMuDQotIEFPQg0KDQpSZXNvdXJjZXM6DQoN
CkxpbmsgdG8gdGhlIENhbHNpZnkgV0cgaXNzdWUgdHJhY2tlcjoNCg0KaHR0cDovL29mY291cnNl
aW1yaWdodC5jb20vY2dpLWJpbi9yb3VuZHVwL2NhbHNpZnkvDQoNCkEgZ29vZCBwbGFjZSB0byBs
ZWFybiBtb3JlIGFib3V0IEphYmJlciBpcyBhdDoNCg0KaHR0cDovL3d3dy5qYWJiZXIub3JnDQoN
ClNlZSB5b3UgdGhlcmUuDQo=

------_=_NextPart_001_01C7138F.AEF9F58B
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C7138F.AEF9F58B
Content-class: urn:content-classes:calendarmessage
Content-Type: text/calendar;
	method=CANCEL;
	name="meeting.ics"
Content-Transfer-Encoding: 8bit

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Olson_20011030_5/Europe/Helsinki
BEGIN:STANDARD
DTSTART:16010101T040000
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
X-MICROSOFT-CDO-MODPROPS;X-MODPARAM=1:BEGIN,dtend,dtstart,END,recurrence-id
DTSTAMP:20061129T082339Z
DTSTART;TZID="/softwarestudio.org/Olson_20011030_5/Europe/Helsinki":2006113
 0T180000
SUMMARY:Cancel: Weekly Jabber Chat
UID:20061127T090257Z-4863-1000-1-0@macbuster
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Calsify W
 G":MAILTO:[email-masked]
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Eliot Lea
 r":MAILTO:[email-masked]
ORGANIZER;CN="Niemi Aki (Nokia-NRC/Helsinki)":MAILTO:[email-masked]
LOCATION:[email-masked]
DTEND;TZID="/softwarestudio.org/Olson_20011030_5/Europe/Helsinki":20061130T
 190000
RRULE:FREQ=DAILY;COUNT=4;INTERVAL=7
DESCRIPTION:After skipping a week due to the US Thanksgiving holiday\, let'
 s continue on our weekly Jabber chats again.\N\NAgenda:\N\N- Agenda bash\,
  setting up\N- Discussing the remaining open issues with RFC 2445bis.\N- A
 OB\N\NResources:\N\NLink to the Calsify WG issue tracker:\N\Nhttp://ofcour
 seimright.com/cgi-bin/roundup/calsify/\N\NA good place to learn more about
  Jabber is at:\N\Nhttp://www.jabber.org\N\NSee you there.
RECURRENCE-ID;TZID="/softwarestudio.org/Olson_20011030_5/Europe/Helsinki":2
 0061130T180000
SEQUENCE:2
PRIORITY:5
CLASS:
CREATED:20061127T070917Z
LAST-MODIFIED:20061127T070917Z
STATUS:CANCELLED
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-OWNERAPPTID:-1
X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20061127T070917Z
X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20061129T082339Z
END:VEVENT
END:VCALENDAR

------_=_NextPart_001_01C7138F.AEF9F58B--

From: Aki Niemi <[email-masked]>
To: Calsify WG <[email-masked]>, Eliot Lear <[email-masked]>
Organization: Nokia-NRC/Helsinki
Date: Mon, 27 Nov 2006 11:08:22 +0200
Subject: [Ietf-calsify] Weekly Jabber Chat

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Olson_20011030_5/Europe/Helsinki
X-LIC-LOCATION:Europe/Helsinki
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:EEST
DTSTART:19700329T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:EET
DTSTART:19701025T040000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:20061127T090257Z-4863-1000-1-0@macbuster
DTSTAMP:20061127T090822Z
DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Helsinki:
 20061130T180000
DTEND;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Helsinki:
 20061130T190000
SEQUENCE:2
SUMMARY:Weekly Jabber Chat
LOCATION:[email-masked]
DESCRIPTION:After skipping a week due to the US Thanksgiving holiday\, 
 let's continue on our weekly Jabber chats again.\n\nAgenda:\n\n- Agenda 
 bash\, setting up\n- Discussing the remaining open issues with RFC 
 2445bis.\n- AOB\n\nResources:\n\nLink to the Calsify WG issue tracker:
 \n\nhttp://ofcourseimright.com/cgi-bin/roundup/calsify/\n\nA good place 
 to learn more about Jabber is at:\n\nhttp://www.jabber.org\n\nSee you 
 there.
CLASS:PUBLIC
TRANSP:OPAQUE
ORGANIZER;CN=Aki Niemi:MAILTO:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;
 RSVP=TRUE;CN=Aki Niemi;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;CN=Calsify WG;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;CN=Eliot Lear;LANGUAGE=en:MAILTO:[email-masked]
RRULE:FREQ=DAILY;COUNT=4;INTERVAL=7
END:VEVENT
END:VCALENDAR

Date: Fri, 17 Nov 2006 15:29:44 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Updated ABNF to address issues 52 & 56
Cc: [email-masked]

+1 (Obviously!)

Cheers,
Bernard

Alexey Melnikov wrote:
> Here is the updated ABNF (based on feedback from Bernard) to address
> 
> * Issue 52: (Section 4.3.10 Recurrence Rule: x-name rule part?)
> * Issue 56: (Section 4.3.10: Order of rule parts (ABNF issue))
> 
> recur           = recur-rule-part *( ";" recur-rule-part )
>                ;
>                ; The rule parts are not ordered in any
>                ; particular sequence
>                ;
>                ; The FREQ rule part is REQUIRED,
>                ; but MUST NOT occur more than once
>                ;
>                ; The UNTIL or COUNT rule parts are OPTIONAL,
>                ; but they MUST NOT occur in the same 'recur'
>                ;
>                ; The other rule parts are OPTIONAL,
>                ; but MUST NOT occur more than once
> 
> recur-rule-part = ( "FREQ" "=" freq )
>                / ( "UNTIL" "=" enddate )
>                / ( "COUNT" "=" 1*DIGIT )
>                / ( "INTERVAL" "=" 1*DIGIT )
>                / ( "BYSECOND" "=" byseclist )
>                / ( "BYMINUTE" "=" byminlist )
>                / ( "BYHOUR" "=" byhrlist )
>                / ( "BYDAY" "=" bywdaylist )
>                / ( "BYMONTHDAY" "=" bymodaylist )
>                / ( "BYYEARDAY" "=" byyrdaylist )
>                / ( "BYWEEKNO" "=" bywknolist )
>                / ( "BYMONTH" "=" bymolist )
>                / ( "BYSETPOS" "=" bysplist )
>                / ( "WKST" "=" weekday )
> 
> Regards,
> Alexey
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 17 Nov 2006 18:58:06 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Updated ABNF to address issues 52 & 56

Here is the updated ABNF (based on feedback from Bernard) to address

* Issue 52: (Section 4.3.10 Recurrence Rule: x-name rule part?)
* Issue 56: (Section 4.3.10: Order of rule parts (ABNF issue))

recur           = recur-rule-part *( ";" recur-rule-part )
                ;
                ; The rule parts are not ordered in any
                ; particular sequence
                ;
                ; The FREQ rule part is REQUIRED,
                ; but MUST NOT occur more than once
                ;
                ; The UNTIL or COUNT rule parts are OPTIONAL,
                ; but they MUST NOT occur in the same 'recur'
                ;
                ; The other rule parts are OPTIONAL,
                ; but MUST NOT occur more than once

recur-rule-part = ( "FREQ" "=" freq )
                / ( "UNTIL" "=" enddate )
                / ( "COUNT" "=" 1*DIGIT )
                / ( "INTERVAL" "=" 1*DIGIT )
                / ( "BYSECOND" "=" byseclist )
                / ( "BYMINUTE" "=" byminlist )
                / ( "BYHOUR" "=" byhrlist )
                / ( "BYDAY" "=" bywdaylist )
                / ( "BYMONTHDAY" "=" bymodaylist )
                / ( "BYYEARDAY" "=" byyrdaylist )
                / ( "BYWEEKNO" "=" bywknolist )
                / ( "BYMONTH" "=" bymolist )
                / ( "BYSETPOS" "=" bysplist )
                / ( "WKST" "=" weekday )

Regards,
Alexey

Date: Fri, 17 Nov 2006 00:29:18 +0100 (MET)
From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: Issue 56: Re: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order of rule parts

Am Donnerstag, 16. November 2006 21:26 schrieben Sie:

> As far as I know, neither RRULE nor EXRULE allowed a comma separated
> list of RECUR values.

> First, if we don't want applications to specify more than one RRULE,
> I don't see the point of allowing properties of RECUR value type to
> specify multiple RECUR values.

Now I remember that discussion. I wasn't aware of it. 

> BTW, Alexey has been given the action item to come up with a new
> "recur" ABNF rule during the Jabber session today.

So it's in good hands then.:)

Regards,

Oliver

-- 
Leben ist mehr als ... 
<http://www.nak-nrw.de/index.php?id=72>

Date: Thu, 16 Nov 2006 16:45:13 -0500
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] Calendar availability specification

Hi folks,
I would like to draw your attention to:

<http://www.ietf.org/internet-drafts/draft-daboo-calendar-availability-00.txt>

This draft defines a new iCalendar component whose purpose is to convey 
user availability time periods. This differs from VFREEBUSY in that the 
components can specify repeating/recurring periods. So it is useful for 
defining regular "office hours" etc.

In addition to defining the new VAVAILABILITY component and explaining how 
it affects free-busy determination, the spec also describes how CalDAV can 
use these in its own free-busy operations.

Please note that discussion of this draft should take place on the 
ietf-caldav mailing list:

<mailto:[email-masked]>

So please reply there with any comments you might have.

This specification comes from work done in the Calendaring & Scheduling 
Consortium and is being submitted to the IETF for further discussion, 
review and hopefully on to standardization. This draft does have a 
dependency on the Calsify 2445bis work (specifically IANA registration of 
the new component), so it will follow that down standardization path.

-- 
Cyrus Daboo

Date: Thu, 16 Nov 2006 16:22:34 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Oliver Block <[email-masked]>
Subject: Re: Issue 56: Re: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order	of rule parts
Cc: [email-masked]

Hi Bernard,

--On November 16, 2006 3:26:48 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> Second, I think it's was a terrible idea to use COMMA as a delimiter
> for multiple RECUR values, given that COMMA is already used as a
> delimiter for multi-valued rule parts.

The only way comma would work is if FREQ were required to be the first item 
in each rule, then you could tell when a new rule part started. But in any 
case we are not allowing multiple rules so it doesn't matter now.

-- 
Cyrus Daboo

Date: Thu, 16 Nov 2006 15:26:48 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Issue 56: Re: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order of rule parts
Cc: [email-masked]

Oliver,

This issue is only about the order of *rule parts* in a RECUR value.
For instance, can one specify:
    RRULE:BYDAY=MO;FREQ=WEEKLY
or does FREQ really need to be the first rule part, that is:
    RRULE:FREQ=WEEKLY;BYDAY=MO

Now, we respect to comma separated list of RECUR values, the text
for the RECUR value type clearly specified "If the property permits".
As far as I know, neither RRULE nor EXRULE allowed a comma separated
list of RECUR values.

You'll notice that I removed the first sentence of the Description
field of the RECUR value type in draft -03 at the same time I
addressed the issue 13, 14, 24 and 25.

First, if we don't want applications to specify more than one RRULE,
I don't see the point of allowing properties of RECUR value type to
specify multiple RECUR values.

Second, I think it's was a terrible idea to use COMMA as a delimiter
for multiple RECUR values, given that COMMA is already used as a
delimiter for multi-valued rule parts.

BTW, Alexey has been given the action item to come up with a new
"recur" ABNF rule during the Jabber session today.

Cheers,
Bernard

Oliver Block wrote:
> Am Sonntag, 5. November 2006 23:24 schrieb Bernard Desruisseaux:
>> In section 4.3.10 Recurrence Rule of RFC 2445 it says:
>> I'm not sure how the "recur" rule should be rewritten.
> 
> from page 118:
>>     rrule      = "RRULE" rrulparam ":" recur CRLF
>>
>>     rrulparam  = *(";" xparam)
> 
> combined with text from page 42:
>>   Description: If the property permits, multiple "recur" values are
>>   specified by a COMMA character (US-ASCII decimal 44) separated list
>>   of values.
> 
> Result:
>>     rrule      = "RRULE" rrulparam ":" recur *("," recur) CRLF
>>
>>     rrulparam  = *(";" xparam)
> 
> 
> from page 42:
> 
>>  The rule parts are separated from each other by
>>   the SEMICOLON character (US-ASCII decimal 59).
> 
> from page 40:
> 
>>     recur      = "FREQ"=freq *( ...)
> 
> Result:
>> recur = rpart *( ";" rpart)
>>
>> rpart = "FREQ" "=" freq 
>>               ( ( ";" "UNTIL" "=" enddate ) /
>>                ( ";" "COUNT" "=" 1*DIGIT ) )
>>
>>                [ ";" "INTERVAL" "=" 1*DIGIT ]
>>                [ ";" "BYSECOND" "=" byseclist ]
>>                [ ";" "BYMINUTE" "=" byminlist ]
>>                [ ";" "BYHOUR" "=" byhrlist ]
>>                [ ";" "BYDAY" "=" bywdaylist ]
>>                [ ";" "BYMONTHDAY" "=" bymodaylist ]
>>                [ ";" "BYYEARDAY" "=" byyrdaylist ]
>>                [ ";" "BYWEEKNO" "=" bywknolist ]
>>                [ ";" "BYMONTH" "=" bymolist ]
>>                [ ";" "BYSETPOS" "=" bysplist ]
>>                [ ";" "WKST" "=" weekday ]
>>                *( ";" x-name "=" text )
>>
> 
> If UNTIL or COUNT are not to be required
> 
>>               ( ( ";" "UNTIL" "=" enddate ) /
>>                ( ";" "COUNT" "=" 1*DIGIT ) )
> 
> should be
> 
>>               *1( ( ";" "UNTIL" "=" enddate ) /
>>                     ( ";" "COUNT" "=" 1*DIGIT ) )
> 
> or
> 
>>               [ ( ";" "UNTIL" "=" enddate ) /
>>                ( ";" "COUNT" "=" 1*DIGIT ) ]
> 
> 
> Regards,
> 
> Oliver
>  
> 

Date: Thu, 16 Nov 2006 16:41:35 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: jabber starts today in 20 minutes

That's 5:00pm CET, 8:00am PST.

Thanks!

Eliot

Date: Thu, 16 Nov 2006 16:24:47 +0100
From: Eliot Lear <[email-masked]>
To: Jonathan Lennox <[email-masked]>
Subject: Re: [Ietf-calsify] DST discontinuities part 2: discontinuities for recurring event start times
Cc: Calsify WG <[email-masked]>

John,

> Issue 2 has to do with how you handle the case when a recurrence's
> start time falls within a discontinuity.
>
> I suggest that by default, the "naive" behavior should be followed: i.e.,
> events that would fall at non-existent times do not occur, and events that
> fall at repeated times occur twice.  Calendar authors that want other
> behaviors should use RDATE and EXDATE to get what they want.
>   

It may be illustrative to note that Vixie cron with the -s flag does not 
behave in this way because it is not what one would want or expect 
intuitively, at least by his estimation.  His changes only involve 
events that occur minutely or hourly.

Eliot

Date: Thu, 16 Nov 2006 16:18:55 +0100
From: Eliot Lear <[email-masked]>
To: Jonathan Lennox <[email-masked]>
Subject: Re: [Ietf-calsify] DST discontinuities part 1: date-times that fall in	discontinutities
Cc: Calsify WG <[email-masked]>

Jonathan Lennox wrote:
> In the meeting today, we brought up the issue of DST discontinuities for
> RRULEs, and Eliot asked for text to be sent to the mailing list.
>
> The first issue has to do with how you handle an ambiguous or nonexistent
> DATE-TIME value.  E.g. (assuming America/New_York describes the U.S. Eastern
> Time Zone) how do you handle the two cases
>
> DTSTART;TZID=America/New_York:20060402T023000 (which does not exist)
>
> DTSTART;TZID=America/New_York:20061029T013000 (which occurs twice)
>
> I would suggest that both these examples be forbidden.  For the latter case,
> clients MUST use UTC (or potentially, some other timezone which does not
> have a jump at that time) to describe the event.
>
>   
Chair hat off, I agree with your suggestion.

Eliot

Date: Thu, 16 Nov 2006 13:29:39 +0100 (MET)
From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order of rule parts

Am Donnerstag, 16. November 2006 12:59 schrieb Oliver Block:

> > recur = rpart *( ";" rpart)
> >
> > rpart = "FREQ" "=" freq
> >               ( ( ";" "UNTIL" "=" enddate ) /
> >                ( ";" "COUNT" "=" 1*DIGIT ) )
> >
> >                [ ";" "INTERVAL" "=" 1*DIGIT ]
> >                [ ";" "BYSECOND" "=" byseclist ]
> >                [ ";" "BYMINUTE" "=" byminlist ]
> >                [ ";" "BYHOUR" "=" byhrlist ]
> >                [ ";" "BYDAY" "=" bywdaylist ]
> >                [ ";" "BYMONTHDAY" "=" bymodaylist ]
> >                [ ";" "BYYEARDAY" "=" byyrdaylist ]
> >                [ ";" "BYWEEKNO" "=" bywknolist ]
> >                [ ";" "BYMONTH" "=" bymolist ]
> >                [ ";" "BYSETPOS" "=" bysplist ]
> >                [ ";" "WKST" "=" weekday ]
> >                *( ";" x-name "=" text )
>

There is a problem with the above. The semicolon should either appear in

> > recur = rpart *( ";" rpart)

or in

> > rpart = ...

Therefore I would change the above to

> > rpart = "FREQ" "=" freq
> >               ( ("UNTIL" "=" enddate ) /
> >                ( "COUNT" "=" 1*DIGIT ) )
> >
> >                [ "INTERVAL" "=" 1*DIGIT ]
> >                [ "BYSECOND" "=" byseclist ]
> >                [ "BYMINUTE" "=" byminlist ]
> >                [ "BYHOUR" "=" byhrlist ]
> >                [ "BYDAY" "=" bywdaylist ]
> >                [ "BYMONTHDAY" "=" bymodaylist ]
> >                [ "BYYEARDAY" "=" byyrdaylist ]
> >                [ "BYWEEKNO" "=" bywknolist ]
> >                [ "BYMONTH" "=" bymolist ]
> >                [ "BYSETPOS" "=" bysplist ]
> >                [ "WKST" "=" weekday ]
> >                *(x-name "=" text )

Regards,

OIiver

-- 
Leben ist mehr als ... 
<http://www.nak-nrw.de/index.php?id=71>

Date: Thu, 16 Nov 2006 12:59:12 +0100 (MET)
From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order of rule parts

Am Sonntag, 5. November 2006 23:24 schrieb Bernard Desruisseaux:
> In section 4.3.10 Recurrence Rule of RFC 2445 it says:
> I'm not sure how the "recur" rule should be rewritten.

from page 118:
>
>     rrule      = "RRULE" rrulparam ":" recur CRLF
>
>     rrulparam  = *(";" xparam)

combined with text from page 42:
>
>   Description: If the property permits, multiple "recur" values are
>   specified by a COMMA character (US-ASCII decimal 44) separated list
>   of values.

Result:
>     rrule      = "RRULE" rrulparam ":" recur *("," recur) CRLF
>
>     rrulparam  = *(";" xparam)

from page 42:

>  The rule parts are separated from each other by
>   the SEMICOLON character (US-ASCII decimal 59).

from page 40:

>     recur      = "FREQ"=freq *( ...)

Result:
> recur = rpart *( ";" rpart)
>
> rpart = "FREQ" "=" freq 
>               ( ( ";" "UNTIL" "=" enddate ) /
>                ( ";" "COUNT" "=" 1*DIGIT ) )
>
>                [ ";" "INTERVAL" "=" 1*DIGIT ]
>                [ ";" "BYSECOND" "=" byseclist ]
>                [ ";" "BYMINUTE" "=" byminlist ]
>                [ ";" "BYHOUR" "=" byhrlist ]
>                [ ";" "BYDAY" "=" bywdaylist ]
>                [ ";" "BYMONTHDAY" "=" bymodaylist ]
>                [ ";" "BYYEARDAY" "=" byyrdaylist ]
>                [ ";" "BYWEEKNO" "=" bywknolist ]
>                [ ";" "BYMONTH" "=" bymolist ]
>                [ ";" "BYSETPOS" "=" bysplist ]
>                [ ";" "WKST" "=" weekday ]
>                *( ";" x-name "=" text )
>

If UNTIL or COUNT are not to be required

>               ( ( ";" "UNTIL" "=" enddate ) /
>                ( ";" "COUNT" "=" 1*DIGIT ) )

should be

>               *1( ( ";" "UNTIL" "=" enddate ) /
>                     ( ";" "COUNT" "=" 1*DIGIT ) )

or

>               [ ( ";" "UNTIL" "=" enddate ) /
>                ( ";" "COUNT" "=" 1*DIGIT ) ]

Regards,

Oliver

-- 
Leben ist mehr als ... 
<http://www.nak-nrw.de/index.php?id=72>

Date: Wed, 15 Nov 2006 10:13:37 -0500
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] Another recurrence rule question

Hi Reinhold,

--On November 15, 2006 3:19:41 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

> Another issue to be cleared in a possible clearing FAQ about RFC 2445.
>
> In a weekly recurrence rule, when exactly is the weekday (Monday,
> Tuesday,  etc.) taken from DTSTART and when not.
> In particular, take a recurrence rule:
>    RRULE:FREQ=WEEKLY
> This event recurs every week on the same weekday as DTSTART.
>
> Now, what about:
>   RRULE:FREQ=WEEKLY;BYMONTHDAY=15
> Does this event recur on every 15 of each month, regardless of the
> weekday, or  on every 15th of each month if it is the same weekday as
> DTSTART?
>
> In other words, does FREQ=WEEKLY always imply an implicit BYDAY=.. (value
> taken from DTSTART)?

I don't see why FREQ=WEEKLY should imply any implicit BYDAY= part. It just 
means repeat the first instance at 7 day intervals. It does not matter what 
day the first instance is. Of course repeating every 7 days means that you 
will always repeat on the same day of the week.

Remember: one change we have agreed upon is that the DTSTART must now match 
the RRULE. So if you did:

RRULE:FREQ=WEEKLY;BYMONTHDAY=15

The DTSTART would have to be the 15th of some month. The week day does not 
enter into it - other than the fact that that is the weekday for all 
instances. If you did:

RRULE:FREQ=WEEKLY;BYMONTHDAY=15;BYDAY=TU

then you would have to specific a DTSTART that was the 15th of some month 
AND a Tuesday.

-- 
Cyrus Daboo

Date: Wed, 15 Nov 2006 09:23:16 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Mike Douglass <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE parameter
Cc: Calsify WG <[email-masked]>

Hi Mike,

We've had this discussion at the last WG meeting in San Diego.

The conclusion was that iCalendar wasn't designed to allow one to
specify property values and property parameter values in multiple
languages, and that one should use other mechanisms to provide
iCalendar data in multiple languages (e.g., multipart/alternative
with iMIP, HTTP content negotiation (RFC2295) with CalDAV).

Cheers,
Bernard

Mike Douglass wrote:
> Would it make sense if all properties that can take a language parameter 
> be allowed to appear multiple times?
> 
> Currently I can internally support multiple languages for a vevent 
> description but there's no legal way to export the entire data as ics.
> 
> There's also no way via caldav for example to update more than one 
> language in a single request
> 
> RFC 2445 has the following properties with a language param:
> 
> ATTENDEE    (cn param)
> CATEGORIES
> COMMENT
> CONTACT
> DESCRIPTION
> LOCATION
> ORGANIZER   (cn param)
> REQUEST-STATUS
> RESOURCES
> SUMMARY
> TZNAME
> 
> 
> 
> Bernard Desruisseaux wrote:
>> RFC 2445 allows some properties of TEXT value type to be specified
>> multiple times. In some cases (e.g., "TZNAME") it is specified that
>> the property can be specified more than once for specifying multiple
>> language variants of the property value.
>>
>> I think section 4.1.2 Multiple Values should clarify how the
>> "LANGUAGE" parameter should be handled with multi-valued TEXT
>> properties.
>>
>> For instance, in a "VJOURNAL" calendar component, can I have two
>> "DESCRIPTION" with "LANGUAGE=en", but only one "DESCRIPTION" with
>> "LANGUAGE=fr"?  If so, should my client only display the one in
>> French, or should it display all three values?
>>
>> Currently, I think it should display all three values...
>>
>> Cheers,
>> Bernard
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>>
> 

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Date: Wed, 15 Nov 2006 15:19:41 +0100
Subject: [Ietf-calsify] Another recurrence rule question

Hi all,

Another issue to be cleared in a possible clearing FAQ about RFC 2445.

In a weekly recurrence rule, when exactly is the weekday (Monday, Tuesday, 
etc.) taken from DTSTART and when not.
In particular, take a recurrence rule:
   RRULE:FREQ=WEEKLY
This event recurs every week on the same weekday as DTSTART.

Now, what about:
  RRULE:FREQ=WEEKLY;BYMONTHDAY=15
Does this event recur on every 15 of each month, regardless of the weekday, or 
on every 15th of each month if it is the same weekday as DTSTART?

In other words, does FREQ=WEEKLY always imply an implicit BYDAY=.. (value 
taken from DTSTART)?

Cheers,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Wed, 15 Nov 2006 09:01:00 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order of rule parts
Cc: [email-masked]

Oliver Block wrote:
> Am Sonntag, 5. November 2006 23:24 schrieb Bernard Desruisseaux:
>> In section 4.3.10 Recurrence Rule of RFC 2445 it says:
>>  > The rule parts are not ordered in any particular sequence.
>>
>> On the other hand, the way the ABNF of the "recur" rule is
>> written, the "FREQ" rule should always appear first.
> 
> Some RFC's explicitly say that text takes precedence over ABNF. That could 
> also be applied here.

It is my understanding that the text takes precedence over the ABNF.
It wouldn't hurt to state it clearly in the document.

> 
>> I'm not sure how the "recur" rule should be rewritten.
>> Any help appreciated...
> 
> I would say that there is a typo in it
> 
>> recur = "FREQ" = freq *( ...)
> 
> should IMHO be
> 
> recur = "FREQ" "=" freq *( ...)

Yep.  It's already fixed in draft -03.

Cheers,
Bernard

> Regards,
> Oliver

Subject: Reminder: calsify Jabber session tomorrow (was: Re: [Ietf-calsify] Jabber session next week)
From: Aki Niemi <[email-masked]>
To: [email-masked]
Organization: Nokia-NRC/Helsinki
Date: Wed, 15 Nov 2006 14:05:42 +0200

As a remainder, we have scheduled a jabber chat for tomorrow, Nov 16, at
17:00 CET / 11:00 EST / 8:00am PST.

Send me a note if you plan to attend. 

Cheers,
Aki

ti, 2006-11-07 kello 14:29 -0800, ext Aki Niemi kirjoitti:
> All,
> 
> During yesterday's WG meeting here in sunny California, we decided to
> continue with our weekly chat sessions.
> 
> However, the usual time was difficult for some, so we decided to propose
> a better one. Does Thursday, November 16, at 17:00 CET / 11:00 EST /
> 8:00am PST work for everyone?
> 
> Send me a note if this works for you; I'll send a calendar invitation to
> this list as well.
> 
> Cheers,
> Aki
> 
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Tue, 14 Nov 2006 16:49:29 +0100 (MET)
From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order of rule parts

Am Sonntag, 5. November 2006 23:24 schrieb Bernard Desruisseaux:
> In section 4.3.10 Recurrence Rule of RFC 2445 it says:
>  > The rule parts are not ordered in any particular sequence.
>
> On the other hand, the way the ABNF of the "recur" rule is
> written, the "FREQ" rule should always appear first.

Some RFC's explicitly say that text takes precedence over ABNF. That could 
also be applied here.

> I'm not sure how the "recur" rule should be rewritten.
> Any help appreciated...

I would say that there is a typo in it

> recur = "FREQ" = freq *( ...)

should IMHO be

recur = "FREQ" "=" freq *( ...)

Regards,

Oliver

-- 
Leben ist mehr als ... 
<http://www.nak-nrw.de/index.php?id=72>

Date: Tue, 14 Nov 2006 09:20:33 -0500
From: Mike Douglass <[email-masked]>
Cc: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE parameter

Would it make sense if all properties that can take a language parameter 
be allowed to appear multiple times?

Currently I can internally support multiple languages for a vevent 
description but there's no legal way to export the entire data as ics.

There's also no way via caldav for example to update more than one 
language in a single request

 RFC 2445 has the following properties with a language param:

 ATTENDEE    (cn param)
 CATEGORIES
 COMMENT
 CONTACT
 DESCRIPTION
 LOCATION
 ORGANIZER   (cn param)
 REQUEST-STATUS
 RESOURCES
 SUMMARY
 TZNAME

Bernard Desruisseaux wrote:
> RFC 2445 allows some properties of TEXT value type to be specified
> multiple times. In some cases (e.g., "TZNAME") it is specified that
> the property can be specified more than once for specifying multiple
> language variants of the property value.
>
> I think section 4.1.2 Multiple Values should clarify how the
> "LANGUAGE" parameter should be handled with multi-valued TEXT
> properties.
>
> For instance, in a "VJOURNAL" calendar component, can I have two
> "DESCRIPTION" with "LANGUAGE=en", but only one "DESCRIPTION" with
> "LANGUAGE=fr"?  If so, should my client only display the one in
> French, or should it display all three values?
>
> Currently, I think it should display all three values...
>
> Cheers,
> Bernard
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Tue, 7 Nov 2006 21:01:55 -0800
From: "Mike Samuel" <[email-masked]>
To: "Jonathan Lennox" <[email-masked]>
Subject: Re: [Ietf-calsify] BYSETPOS and contracting BY* rules
Cc: Calsify WG <[email-masked]>
Reply-To: [email-masked]

On 06/11/06, Jonathan Lennox <[email-masked]> wrote:
> In a hallway discussion today, I happened to remember another ambiguity in
> the iCalendar spec, which was brought up back on the old ietf-calendar
> mailing list but not, I think, ever resolved.
>
> The issue is that BYSETPOS is specified only as
>
>     The BYSETPOS rule part specifies a COMMA character (US-ASCII
>     decimal 44) separated list of values which corresponds to the nth
>     occurrence within the set of events specified by the rule.
>
> and the meaning of "the set of events specified by the rule" is very
> unclear.
>
> Particularly, the case that none of the RFC 2445 examples illustrates is
> what happens when BYSETPOS is used in conjunction with contracting BY*
> rules, i.e. BY* rules describing intervals larger than the FREQ.
>
> The examples I came up with back in June 2001 (see the thread starting at
> <http://www.imc.org/ietf-calendar/mail-archive/thrd11.html#01781> if you
> really care about all the gory details) were:
>
>        RRULE:DTSTART;TZID=America/New_York:20010401T090000
>        RECUR:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1
>
>        RRULE:DTSTART;TZID=America/New_York:20010401T090000
>        RECUR:FREQ=MONTHLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1
>
>        RRULE:DTSTART;TZID=America/New_York:20010401T090000
>        RECUR:FREQ=YEARLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1
>
> My proposal at the time was that these mean, respectively, "the last Friday
> of the week, in April and June" (i.e. "Fridays in April and June", with
> BYSETPOS irrelevant); "the last Friday of April, and the last Friday of
> June"; and "the last Friday of (April or June)" (i.e., given DTSTART, "the
> last Friday of June").
>
> I still think this is right, but at the time not everyone agreed.
>
> (Note that these examples don't obey the new "DTSTART must be a set member"
> constraint.  It's an interesting question how to obey that for rules that
> contain "BYSETPOS=-1".)
>
> Eric Busboom's 2445 revision draft at the time defined this by saying
>
>        BYSETPOS operates on a set of events in one interval of the
>        recurrence rule. For a WEEKLY rule, the interval is one week, for a
>        MONTHLY rule, one month, and for a YEARLY rule, one year.
>
> This wording seems not to have made it into the current 2445bis draft.
>
> How do existing CUAs (if they implement BYSETPOS at all) interpret my three
> examples above?  Do people agree with my suggested interpretation?

Google Calendar will generate each Friday in April and June for
FREQ=WEEKLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1

It applies the BYSETPOS to each period, so each week independently in
this case..  Since the set of Fridays in a given week has cardinality
1, the BYSETPOS has no effect.

Date: Tue, 7 Nov 2006 20:56:02 -0800
From: "Mike Samuel" <[email-masked]>
To: "Jonathan Lennox" <[email-masked]>
Subject: Re: [Ietf-calsify] BYDAY integers with other BY* rules (was: BYSETPOS and contracting BY* rules)
Cc: [email-masked]
Reply-To: [email-masked]

On 07/11/06, Jonathan Lennox <[email-masked]> wrote:
> On Tuesday, November 7 2006, "Reinhold Kainhofer" wrote to "[email-masked]" saying:
>
> > AFAIU RFC 2445, the -1FR means the last friday in the set of dates that match
> > the rule evaluation so far. Thus, I get the same results as with BYSETPOS:
>
> I've always agreed with your second interpretation of RFC 2445: the numbers
> in the BYDAY rule refer to the period of time described by the FREQ.  "-1FR"
> means the last Friday of the month in a MONTHLY rule, and the last Friday of
> the year in a YEARLY rule.
>
> This seems to me to be the most straightforward reading of the BYDAY
> definition:
>
>       Each BYDAY value can also be preceded by a positive (+n) or
>       negative (-n) integer.  If present, this indicates the nth
>       occurrence of the specific day within the MONTHLY or YEARLY RRULE.
>       For example, within a MONTHLY rule, +1MO (or simply 1MO)
>       represents the first Monday within the month, whereas -1MO
>       represents the last Monday of the month.  If an integer modifier
>       is not present, it means all days of this type within the
>       specified frequency.  For example, within a MONTHLY rule, MO
>       represents all Mondays within the month.
>
> That would indeed mean that the other BY* rules in the rule aren't relevant
> to the interpretation of BYDAY, and that the order of interpretation of BY*
> rules other than BYSETPOS isn't important.
>
> Unfortunately, this interpretation is directly contradicted by RFC 2445's
> VTIMEZONE example, which describes US-Eastern DST transitions as
>
>         RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
>

> I've always interpreted this VTIMEZONE example as a bug in the spec, but I
> see how it can make sense if BYDAY integers are interpreted as being like
> BYSETPOS.
>
> What do other implementations do?

Google Calendar treats this as the last Sunday of the year, if it
happens to fall in October, which it never can, so this recurrence
will generate no results.

From: Aki Niemi <[email-masked]>
To: [email-masked], Eliot Lear <[email-masked]>
Organization: Nokia-NRC/Helsinki
Date: Tue, 07 Nov 2006 22:33:35 +0000
Subject: [Ietf-calsify] Calsify Jabber chat session

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Olson_20011030_5/Europe/Helsinki
X-LIC-LOCATION:Europe/Helsinki
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:EEST
DTSTART:19700329T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:EET
DTSTART:19701025T040000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:20061107T220248Z-6983-1000-1-0@macbuster
DTSTAMP:20061107T223333Z
DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Helsinki:
 20061116T180000
DTEND;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Helsinki:
 20061116T190000
SEQUENCE:5
SUMMARY:Calsify Jabber chat session
LOCATION:[email-masked]
CLASS:PUBLIC
ORGANIZER;CN=Aki Niemi:MAILTO:[email-masked]
CREATED:20061107T222919
LAST-MODIFIED:20061107T223248
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
TRANSP:OPAQUE
DESCRIPTION:Please RSVP to me either using iTIP or via email.\n\nAgenda:
 \n\nDiscussing the remaining open issues.\n\nResources:\n\nLink to the 
 Calsify WG issue tracker:\n\nhttp:
 //ofcourseimright.com/cgi-bin/roundup/calsify/\n\nA good place to learn 
 more about Jabber is at:\n\nhttp://www.jabber.org\n\nSee you there.
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;
 RSVP=TRUE;CN=Aki Niemi;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;CN=Eliot Lear;LANGUAGE=en:MAILTO:[email-masked]
END:VEVENT
END:VCALENDAR

Date: Tue, 07 Nov 2006 14:29:05 -0800
From: Aki Niemi <[email-masked]>
Organization: Nokia-NRC/Helsinki
To: [email-masked]
Subject: [Ietf-calsify] Jabber session next week

All,

During yesterday's WG meeting here in sunny California, we decided to
continue with our weekly chat sessions.

However, the usual time was difficult for some, so we decided to propose
a better one. Does Thursday, November 16, at 17:00 CET / 11:00 EST /
8:00am PST work for everyone?

Send me a note if this works for you; I'll send a calendar invitation to
this list as well.

Cheers,
Aki

From: Jonathan Lennox <[email-masked]>
Date: Tue, 7 Nov 2006 11:43:47 -0500
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] RRULEs with DTSTART and DTEND in different time zones

People have mentioned that the case needs to be handled when DTSTART and
DTEND are in different time zones -- for example, for plane flights.

Have people thought about what this means for recurrence durations, when the
two time zones have varying relative UTC offsets?

Specifically:

   DTSTART;TZID=America/Phoenix:20061027T150000
   DTEND;TZID=America/Los_Angeles:20061027T160000
   RRULE:FREQ=WEEKLY;COUNT=2

The first instance of the recurrence starts at 2006-10-27 15:00:00 MST (GMT+7), and
ends at 2006-10-27 16:00:00 PDT (GMT+7), 1 hour later.

The second instance of the recurrence starts at 2006-11-03 15:00:00 MST
(GMT+7), and ends -- when?  One could argue for either 2006-11-03 15:00:00
PST (GMT+8), 1 hour later, or 2006-11-03 16:00:00 PST (GMT+8), 2 hours
later.

Does anyone handle this case?  If UIs allow separate timezones for event
starting and ending times, this actually seems like something that could
poentially be constructed in a calendar UI.

-- 
Jonathan Lennox
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Tue, 7 Nov 2006 09:55:04 -0500
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] BYDAY integers with other BY* rules (was: BYSETPOS and contracting BY* rules)
Cc: [email-masked]

On Tuesday, November 7 2006, "Reinhold Kainhofer" wrote to "[email-masked]" saying:

> AFAIU RFC 2445, the -1FR means the last friday in the set of dates that match 
> the rule evaluation so far. Thus, I get the same results as with BYSETPOS:

I've always agreed with your second interpretation of RFC 2445: the numbers
in the BYDAY rule refer to the period of time described by the FREQ.  "-1FR"
means the last Friday of the month in a MONTHLY rule, and the last Friday of
the year in a YEARLY rule.

This seems to me to be the most straightforward reading of the BYDAY
definition:

      Each BYDAY value can also be preceded by a positive (+n) or
      negative (-n) integer.  If present, this indicates the nth
      occurrence of the specific day within the MONTHLY or YEARLY RRULE.
      For example, within a MONTHLY rule, +1MO (or simply 1MO)
      represents the first Monday within the month, whereas -1MO
      represents the last Monday of the month.  If an integer modifier
      is not present, it means all days of this type within the
      specified frequency.  For example, within a MONTHLY rule, MO
      represents all Mondays within the month.

That would indeed mean that the other BY* rules in the rule aren't relevant
to the interpretation of BYDAY, and that the order of interpretation of BY*
rules other than BYSETPOS isn't important.

Unfortunately, this interpretation is directly contradicted by RFC 2445's
VTIMEZONE example, which describes US-Eastern DST transitions as

        RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10

I've always interpreted this VTIMEZONE example as a bug in the spec, but I
see how it can make sense if BYDAY integers are interpreted as being like
BYSETPOS.

What do other implementations do?

-- 
Jonathan Lennox
[email-masked]

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] BYSETPOS and contracting BY* rules
Date: Tue, 7 Nov 2006 11:21:52 +0100

Am Dienstag, 7. November 2006 04:13 schrieb Jonathan Lennox:
> The examples I came up with back in June 2001 (see the thread starting at
> <http://www.imc.org/ietf-calendar/mail-archive/thrd11.html#01781> if you
> really care about all the gory details) were:
>
> =A0 =A0 =A0 =A0RRULE:DTSTART;TZID=3DAmerica/New_York:20010401T090000
> =A0 =A0 =A0 =A0RECUR:FREQ=3DWEEKLY;BYMONTH=3D4,6;BYDAY=3DFR;BYSETPOS=3D-1
>
> =A0 =A0 =A0 =A0RRULE:DTSTART;TZID=3DAmerica/New_York:20010401T090000
> =A0 =A0 =A0 =A0RECUR:FREQ=3DMONTHLY;BYMONTH=3D4,6;BYDAY=3DFR;BYSETPOS=3D-1
>
> =A0 =A0 =A0 =A0RRULE:DTSTART;TZID=3DAmerica/New_York:20010401T090000
> =A0 =A0 =A0 =A0RECUR:FREQ=3DYEARLY;BYMONTH=3D4,6;BYDAY=3DFR;BYSETPOS=3D-1
>
> My proposal at the time was that these mean, respectively, "the last Frid=
ay
> of the week, in April and June" (i.e. "Fridays in April and June", with
> BYSETPOS irrelevant); "the last Friday of April, and the last Friday of
> June"; and "the last Friday of (April or June)" (i.e., given DTSTART, "the
> last Friday of June").

I think so, too.

A similar issue happens with BYDAY, which is similar to BYSETPOS, only that=
 it=20
is evaluated before all BY(HOUR|MINUTE|SECOND) are evaluated and that it ha=
s=20
an additional constraint of giving one or more weekdays, too.

        DTSTART;TZID=3DAmerica/New_York:20010401T090000
        RRULE:FREQ=3DWEEKLY;BYMONTH=3D4,6;BYDAY=3D-1FR

        DTSTART;TZID=3DAmerica/New_York:20010401T090000
        RRULE:FREQ=3DMONTHLY;BYMONTH=3D4,6;BYDAY=3D-1FR

        DTSTART;TZID=3DAmerica/New_York:20010401T090000
        RRULE:FREQ=3DYEARLY;BYMONTH=3D4,6;BYDAY=3D-1FR

AFAIU RFC 2445, the -1FR means the last friday in the set of dates that mat=
ch=20
the rule evaluation so far. Thus, I get the same results as with BYSETPOS:

In the first example, where we loop over each week, that set contains only =
one=20
Mon-Sun of that week, so the -1 is irrelevant.
In the second example, we loop over all months, the bymonth returns an empt=
y=20
set for all months other than april and jung. But in april and in june, the=
=20
set contains all days of that month, so -1FR is the last friday of april wh=
en=20
the loop is in april, and the last friday of june, when the loop reache jun=
e.
In the third example, we loop over all years, then choose only all days fro=
m=20
april and june, and finally the BYDAY selects the last friday of that set,=
=20
which is the last friday of june.

It's even more interesting when we add BYWEEKNO...

Or am I misunderstanding the BYDAY rule part here, and=20
        RRULE:FREQ=3DYEARLY;BYWEEKNO=3D3;BYDAY=3D-1FR
matches only the last friday of the year if it is in week #3?
If so, why is the order of the evaluation relevant? The only thing that is=
=20
important in that case is that BYSETPOS are evaluated last, all other BY*=20
rule parts else can be evaluated in any order...

That's another example that would help a lot if it appeared in an official=
=20
=46AQ. As I already mentioned several times, the RFC explains only some ver=
y=20
simple RRULEs, which are quite clear anyway, but forgets to give examples=20
where the details are important (e.g. in the examples given, the order of t=
he=20
evaluation of the rule parts is irrelevant, while in reality there are=20
several cases, where you get a different result if you evaluate the parts i=
n=20
a different order).

Cheers,
Reinhol
 =20
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE parameter
Date: Mon, 6 Nov 2006 22:31:28 -0500

The MIME approach makes all of the components in an iCalendar/iTIP set
match, language-wise, which probably is a good thing.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Monday, November 06, 2006 10:04 AM
To: Bernard Desruisseaux; Calsify WG
Subject: Re: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE
parameter

Hi Bernard,

--On November 5, 2006 5:29:25 PM -0500 Bernard Desruisseaux
<[email-masked]> wrote:

> RFC 2445 allows some properties of TEXT value type to be specified 
> multiple times. In some cases (e.g., "TZNAME") it is specified that 
> the property can be specified more than once for specifying multiple 
> language variants of the property value.
>
> I think section 4.1.2 Multiple Values should clarify how the 
> "LANGUAGE" parameter should be handled with multi-valued TEXT 
> properties.
>
> For instance, in a "VJOURNAL" calendar component, can I have two 
> "DESCRIPTION" with "LANGUAGE=en", but only one "DESCRIPTION" with 
> "LANGUAGE=fr"?  If so, should my client only display the one in 
> French, or should it display all three values?
>
> Currently, I think it should display all three values...

Its really not clear how multi-lingual 'alternatives' of an iCalendar
component should be handled. The suggestion of using multiple properties
with different LANGUAGES really does not work as there is no way to
unambiguously tie the variants together as alternatives.

A better approach might be to say that language alternatives should be
constructed at the MIME level - i.e. as separate components in separate MIME
parts inside a multipart/alternative.

--
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Jonathan Lennox <[email-masked]>
Date: Mon, 6 Nov 2006 22:13:42 -0500
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] BYSETPOS and contracting BY* rules

In a hallway discussion today, I happened to remember another ambiguity in
the iCalendar spec, which was brought up back on the old ietf-calendar
mailing list but not, I think, ever resolved.

The issue is that BYSETPOS is specified only as

    The BYSETPOS rule part specifies a COMMA character (US-ASCII
    decimal 44) separated list of values which corresponds to the nth
    occurrence within the set of events specified by the rule. 

and the meaning of "the set of events specified by the rule" is very
unclear.

Particularly, the case that none of the RFC 2445 examples illustrates is
what happens when BYSETPOS is used in conjunction with contracting BY*
rules, i.e. BY* rules describing intervals larger than the FREQ.

The examples I came up with back in June 2001 (see the thread starting at
<http://www.imc.org/ietf-calendar/mail-archive/thrd11.html#01781> if you
really care about all the gory details) were:

       RRULE:DTSTART;TZID=America/New_York:20010401T090000
       RECUR:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1

       RRULE:DTSTART;TZID=America/New_York:20010401T090000
       RECUR:FREQ=MONTHLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1

       RRULE:DTSTART;TZID=America/New_York:20010401T090000
       RECUR:FREQ=YEARLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1

My proposal at the time was that these mean, respectively, "the last Friday
of the week, in April and June" (i.e. "Fridays in April and June", with
BYSETPOS irrelevant); "the last Friday of April, and the last Friday of
June"; and "the last Friday of (April or June)" (i.e., given DTSTART, "the
last Friday of June").

I still think this is right, but at the time not everyone agreed.

(Note that these examples don't obey the new "DTSTART must be a set member"
constraint.  It's an interesting question how to obey that for rules that
contain "BYSETPOS=-1".)

Eric Busboom's 2445 revision draft at the time defined this by saying

       BYSETPOS operates on a set of events in one interval of the
       recurrence rule. For a WEEKLY rule, the interval is one week, for a
       MONTHLY rule, one month, and for a YEARLY rule, one year.

This wording seems not to have made it into the current 2445bis draft.

How do existing CUAs (if they implement BYSETPOS at all) interpret my three
examples above?  Do people agree with my suggested interpretation?

-- 
Jonathan Lennox
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Mon, 6 Nov 2006 19:37:09 -0500
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] The "other" time discontinuity: leap-seconds

While I was thinking about the DST discontinuities, it occurred to me that
we should also address the "other" time discontinuity, leap-seconds.

My proposal is that iCalendar be completely ignorant of leap-seconds,
i.e. treat time as a fixed-radix 24:60:60 timescale.  (Pedants can treat
this as UT1, TAI, or "POSIX Time", as they like.)

Thus, calendar authors MUST NOT put "60" in the seconds field of a DATE-TIME
value, and the "nominal duration" rules assume that there are always 60
seconds in a minute.

That is, all occurences of each of the following events end at 00:00:00 of
the day after they start (even though there was a leap second at 2005-12-31
23:59:60 UTC):

DTSTART:20051231T235900Z
DURATION:PT1M

DTSTART:20051231T235900Z
DURATION:PT60S

DTSTART:20051231T235900Z
DURATION:PT1M
FREQ=DAILY;COUNT=2

DTSTART:20051231T235900Z
DURATION:PT60S
FREQ=DAILY;COUNT=2

DTSTART:20051230T235900Z
DURATION:PT1M
FREQ=DAILY;COUNT=2

DTSTART:20051230T235900Z
DURATION:PT60S
FREQ=DAILY;COUNT=2

I feel quite confident that this is the behavior you'll see from every
existing calendaring client.

-- 
Jonathan Lennox
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Mon, 6 Nov 2006 19:21:41 -0500
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] DST discontinuities part 3: discontinuities for event end times

My third issue has to do with how you handle the case when an event's end
time "would" occur within a DST discontinuity.

It's hard to even define this issue without a resolution to Issue 27 -- what
DTEND/DURATION mean for events that cross a DST transition.

It sounded like the consensus in the room was leaning towards the idea that
durations are "nominal" durations, not "real" durations, i.e. in
America/New_York, a PT8H event that starts at 2006-04-02 00:00:00, or
2006-10-29 00:00:00, ends at 08:00:00 in both cases (for a real duration of
seven hours or nine hours, respectively).

If that is indeed the case, the question needs to be answered: when does the
event

   DTSTART;TZID=America/New_York:20060402T000000
   DURATION:PT2H30M

end?  The nominal duration would imply an end at 2006-04-02 02:30:00, which
in America/New_York doesn't exist.

Similarly, the nominal-duration rules would indicate that

   DTSTART;TZID=America/New_York:20061029T000000
   DURATION:PT1H30M

would end at 2006-10-29 01:30:00, which could refer to either 2006-10-29
01:30:00 EDT or 2006-10-29 01:30:00 EST.

To be clear, the fact that my examples used sub-day duration lengths isn't
relevant here; the problem also occurs with 

   DTSTART;TZID=America/New_York:20060401T023000
   DURATION:P1D

   DTSTART;TZID=America/New_York:20061028T013000
   DURATION:P1D

as well.  My inclination would be to say that the resolution should be the
same for these both cases, but others may disagree.

This issue is the same both for single events and for recurring events, i.e.

   DTSTART;TZID=America/New_York:20060331T023000
   DURATION:P1D
   RRULE:FREQ=DAILY;COUNT=2

   DTSTART;TZID=America/New_York:20061027T013000
   DURATION:P1D
   RRULE:FREQ=DAILY;COUNT=2

have this problem for their second occurrence.

-- 
Jonathan Lennox
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Mon, 6 Nov 2006 18:57:29 -0500
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] DST discontinuities part 2: discontinuities for recurring event start times

Issue 2 has to do with how you handle the case when a recurrence's
start time falls within a discontinuity.

I suggest that by default, the "naive" behavior should be followed: i.e.,
events that would fall at non-existent times do not occur, and events that
fall at repeated times occur twice.  Calendar authors that want other
behaviors should use RDATE and EXDATE to get what they want.

(If existing clients consistently do something different, we should define
that behavior instead; this could use testing.)

The two relevant examples are, first, a forward jump in time:

   DTSTART;TZID=America/New_York:20060331T023000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=4

In my suggested resolution, the event recurs at:

2006-03-31 02:30:00 EST
2006-04-01 02:30:00 EST
2006-04-03 02:30:00 EDT
2006-04-04 02:30:00 EDT

The second example, a backward jump in time:

   DTSTART;TZID=America/New_York:20061028T013000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=4

In my suggested resolution, the event recurs at:

2006-10-28 01:30:00 EDT
2006-10-29 01:30:00 EDT
2006-10-29 01:30:00 EST
2006-10-30 01:30:00 EST

-- 
Jonathan Lennox
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Mon, 6 Nov 2006 18:52:23 -0500
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] DST discontinuities part 1: date-times that fall in discontinutities

In the meeting today, we brought up the issue of DST discontinuities for
RRULEs, and Eliot asked for text to be sent to the mailing list.

The first issue has to do with how you handle an ambiguous or nonexistent
DATE-TIME value.  E.g. (assuming America/New_York describes the U.S. Eastern
Time Zone) how do you handle the two cases

DTSTART;TZID=America/New_York:20060402T023000 (which does not exist)

DTSTART;TZID=America/New_York:20061029T013000 (which occurs twice)

I would suggest that both these examples be forbidden.  For the latter case,
clients MUST use UTC (or potentially, some other timezone which does not
have a jump at that time) to describe the event.

-- 
Jonathan Lennox
[email-masked]

Date: Mon, 06 Nov 2006 13:37:03 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Default duration of	day events
Cc: Calsify WG <[email-masked]>

Hi Cyrus,

 > This issue begs the question of whether all day events should
 > automatically appear as opaque in free-busy lookups. I suspect most
 > implementations do not add TRANS:TRANSPARENT when adding an
 > 'anniversary' event - but having that block out time would be bad.

If so, please provide a list of such implementations.

 From what I've seen, implementations do specify DTEND or DURATION and
TRANSP explicitly.  As such, in most cases there are no ambiguity.

 >
 > This would be a change to 2445, but one solution is to say the default
 > TRANSP for all day events is TRANSPARENT rather than OPAQUE.
 >

I'd prefer not to introduce an exception for all day events.

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Bernard,
> 
> --On November 5, 2006 5:26:48 PM -0500 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
>> In section 4.6.1 Event Component of RFC 2445 it says:
>>
>>  > For cases where a "VEVENT" calendar component specifies a "DTSTART"
>>  > property with a DATE data type but no "DTEND" property, the events
>>  > non-inclusive end is the end of the calendar date specified by the
>>  > "DTSTART" property.
>>
>> As such, the last sentence of the paragraph before the following example
>> is wrong. This event would actually appear as opaque in a search for busy
>> time.
>>
>>  > The following is an example of the "VEVENT" calendar component used
>>  > to represent an anniversary that will occur annually. Since it takes
>>  > up no time, it will not appear as opaque in a search for busy time;
>>  > no matter what the value of the "TRANSP" property indicates:
>>  >
>>  >   BEGIN:VEVENT
>>  >   UID:[email-masked]
>>  >   DTSTAMP:19970901T1300Z
>>  >   DTSTART:19971102
>>  >   SUMMARY:Our Blissful Anniversary
>>  >   CLASS:CONFIDENTIAL
>>  >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
>>  >   RRULE:FREQ=YEARLY
>>  >   END:VEVENT
>>
>> I propose to remove this sentence and to add the TRANSP property to
>> the example.
>>
>> Proposed text:
>>
>>  > The following is an example of the "VEVENT" calendar component used
>>  > to represent an anniversary that will occur annually.
>>  >
>>  >   BEGIN:VEVENT
>>  >   UID:[email-masked]
>>  >   DTSTAMP:19970901T1300Z
>>  >   DTSTART:19971102
>>  >   SUMMARY:Our Blissful Anniversary
>>  >   TRANSP:TRANSPARENT
>>  >   CLASS:CONFIDENTIAL
>>  >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
>>  >   RRULE:FREQ=YEARLY
>>  >   END:VEVENT
>>
>> Similarly, in section 4.8.2.4 Date/Time Start of RFC 2445 it says:
>>
>>  > Description: Within the "VEVENT" calendar component, this property
>>  > defines the start date and time for the event. The property is
>>  > REQUIRED in "VEVENT" calendar components. Events can have a start
>>  > date/time but no end date/time. In that case, the event does not take
>>  > up any time.
>>
>> I propose to remove the last two sentences of this paragraph.
>>
>> Proposed text:
>>
>>  > Description: Within the "VEVENT" calendar component, this property
>>  > defines the start date and time for the event. The property is
>>  > REQUIRED in "VEVENT" calendar components.
>>
>> Finally, in section 6 Recommended Practices of RFC 2445 it says:
>>
>>  > 2.  A calendar entry with a "DTSTART" property but no "DTEND"
>>  >     property does not take up any time. It is intended to represent
>>  >     an event that is associated with a given calendar date and time
>>  >     of day, such as an anniversary. Since the event does not take up
>>  >     any time, it MUST NOT be used to record busy time no matter what
>>  >     the value for the "TRANSP" property.
>>
>> This is actually wrong. I would simply remove this text. The proper
>> behave is described in section 4.6.1 Event Component.
> 
> This issue begs the question of whether all day events should 
> automatically appear as opaque in free-busy lookups. I suspect most 
> implementations do not add TRANS:TRANSPARENT when adding an 
> 'anniversary' event - but having that block out time would be bad.
> 
> This would be a change to 2445, but one solution is to say the default 
> TRANSP for all day events is TRANSPARENT rather than OPAQUE.
> 

Date: Mon, 06 Nov 2006 08:59:07 -0800
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Lisa Dusseault <[email-masked]>, Cyrus Daboo <[email-masked]>, Aki Niemi <[email-masked]>, Alexey Melnikov <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Calsify Lunch is @ 11:45 at the restaurant in the Main Sheraton Tower (East)

We have a reservation for 10.  This includes authors, chairs, AD.  
Others are welcome as the reservation permits.

Eliot

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART
Date: Mon, 6 Nov 2006 08:49:30 -0800
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

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

That's one of those cases that I think we could handle *not* having  
all in the same recurrence rule, or by having EXDates rather than  
make RDATE an implicit EXDATE.  There are so many ways of expressing  
the logical meeting you describe...

Lisa

On Nov 6, 2006, at 6:00 AM, Bernard Desruisseaux wrote:

>
> Let's say I want to have a meeting today (Monday) with three
> further instances on the next upcoming Tuesday. I could easily
> do that with an RDATE set to today (Monday) and a DTSTART set
> to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.

--Apple-Mail-3--159023265
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">That's one of those cases that I =
think we could handle *not* having all in the same recurrence rule, or =
by having EXDates rather than make RDATE an implicit EXDATE.=A0 There =
are so many ways of expressing the logical meeting you =
describe...<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa<DIV><BR><DIV><DIV>On =
Nov 6, 2006, at 6:00 AM, Bernard Desruisseaux wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; =
min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Let's say I want to have a meeting today (Monday) with =
three</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">further =
instances on the next upcoming Tuesday. I could easily</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">do that with an RDATE set to =
today (Monday) and a DTSTART set</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">to tomorrow (Tuesday) and =
RRULE:FREQ=3DWEEKLY;BYDAY=3DTU;COUNT=3D3.</FONT></P> =
</BLOCKQUOTE></DIV><BR></DIV></DIV></BODY></HTML>=

--Apple-Mail-3--159023265--

Date: Mon, 06 Nov 2006 10:45:48 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.8.2 Request Status: 3-tuples or pairs?
Cc: Calsify WG <[email-masked]>

Cyrus,

I think we should only allow pairs and 3-tuples, as such it should be:

statcode   = 1*DIGIT 1*2("." 1*DIGIT)
                      ^
Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Bernard,
> 
> --On November 5, 2006 5:33:51 PM -0500 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
>> In Section 4.8.8.2 Request Status of RFC 2445 it says:
>>
>>  > The short return status is a PERIOD character (US-ASCII decimal 46)
>>  > separated 3-tuple of integers. For example, "3.1.1". The successive
>>  > levels of integers provide for a successive level of status code
>>  > granularity.
>>
>> But all the examples in the draft specify REQUEST-STATUS values with
>> only a pair of integers (e.g., "2.0").
>>
>> Furthermore, all the values specified in section 3.6 Status Replies of
>> RFC 2246 are only pair of integers.
>>
>> I see two options:
>>
>> a) Change text to allow pairs and 3-tuples;
>>
>> b) Change text to allow pairs only.
> 
> Actually the ABNF for statuscode shows that it can contain an arbitrary 
> number of 'tuples':
> 
> statcode   = 1*DIGIT *("." 1*DIGIT)
> 
> What we could do is:
> 
> statcode   = 1*DIGIT *2("." 1*DIGIT)
> 
> That would allow for up to three levels of tuples. It would be 
> consistent with the ones currently defined in 2445/2446.
> 

From: Jay Batson <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.3 Journal Component: DESCRIPTION property
Date: Mon, 6 Nov 2006 10:41:47 -0500
To: Calsify WG <[email-masked]>

On Nov 6, 2006, at 9:57 AM, Cyrus Daboo wrote:
> Hi Bernard,
> --On November 5, 2006 5:27:32 PM -0500 Bernard Desruisseaux  
> <[email-masked]> wrote:
>>  > jourprop   = *(
>>  >
>>  >            ; the following are optional,
>>  >            ; but MUST NOT occur more than once
>>  >
>>  >            class / created / description / dtstart / dtstamp /
>>  >            last-mod / organizer / recurid / seq / status /
>>  >            summary / uid / url /
>>
>> But according to section 4.8.1.5 Description, the "DESCRIPTION"
>> property can be specified multiple times within a "VJOURNAL"
>> calendar component.
>>
>> As such, I propose to modify the "jourprop" rule in section
>> 4.6.3 to be in accordance with the text in section 4.8.1.5.
>
> +1

+1

-------------
Jay Batson
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

Date: Mon, 06 Nov 2006 07:32:02 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: Allowed forms for	aDATE-TIME
Cc: 'Calsify WG' <[email-masked]>

Hi Bernard,

--On November 5, 2006 6:53:01 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

>> Wait! Are you saying that recurrence rules cannot use "floating"
>> date-time?
>
> Humm.  I was.  On second thought, I realize that this needs to be
> possible.
>
>> There's a very good use case for it: conference scheduling. There might
>> be an "administrivia" meeting every morning of the conference week at
>> the same time and place - a clear case for recurrence - yet, many
>> attendees do not like to set their devices to the local time of the
>> conference (unless the device changes to local time automatically as
>> cell phones do) and so the conference schedule is published in
>> "floating" time.
>
> I don't believe anybody should publish a conference schedule in "floating
> time", but I agree that one might want to publish recurring floating
> events such as "Lunch" or "Diner"...

Yes - we must allow floating time recurring events.

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:30:47 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.8.2 Request Status: 3-tuples or pairs?

Hi Bernard,

--On November 5, 2006 5:33:51 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> In Section 4.8.8.2 Request Status of RFC 2445 it says:
>
>  > The short return status is a PERIOD character (US-ASCII decimal 46)
>  > separated 3-tuple of integers. For example, "3.1.1". The successive
>  > levels of integers provide for a successive level of status code
>  > granularity.
>
> But all the examples in the draft specify REQUEST-STATUS values with
> only a pair of integers (e.g., "2.0").
>
> Furthermore, all the values specified in section 3.6 Status Replies of
> RFC 2246 are only pair of integers.
>
> I see two options:
>
> a) Change text to allow pairs and 3-tuples;
>
> b) Change text to allow pairs only.

Actually the ABNF for statuscode shows that it can contain an arbitrary 
number of 'tuples':

statcode   = 1*DIGIT *("." 1*DIGIT)

What we could do is:

statcode   = 1*DIGIT *2("." 1*DIGIT)

That would allow for up to three levels of tuples. It would be consistent 
with the ones currently defined in 2445/2446.

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:25:19 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.2.5 Duration: VFREEBUSY request

Hi Bernard,

--On November 5, 2006 5:36:05 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

>  > In a "VFREEBUSY" calendar component the property may be
>  > used to specify the interval of free time being requested.
>
> Yet, section 3.3.2 REQUEST of RFC 2446 (iTIP) specifies that
> the DURATION property is not allowed in a VFREEBUSY request.
>
> I see three options:
>
> a) Remove statement from iCalendar to be in sync with iTIP;
>
> b) Change iTIP to allow the DURATION property in a VFREEBUSY
>     request and define the semantic as specified in iCalendar.
>
> c) Status quo.

We should rule out (c) as it represents an inconsistency between the two 
specs. Note that 2445 does not clearly define what it means to have 
DURATION present. e.g. is it allowed for the responder to only return free 
times slots that are equal to or larger than the DURATION, or should they 
still return the full list? If we can clearly specify the behavior then I 
think (b) is reasonable, otherwise we have to do (a).

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:17:35 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 6 Recommended Practices #4: Precedence of	duration of RDATE

Hi Bernard,

--On November 5, 2006 5:35:33 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> In section 6 Recommended Practices of RFC 2445 it says:
>
>  > 4.  When the combination of the "RRULE" and "RDATE" properties on an
>  >     iCalendar object produces multiple instances having the same
>  >     start date/time, they should be collapsed to, and considered as,
>  >     a single instance.
>
> We should probably clarify that if the "RDATE" property is specified as
> a PERIOD, its duration has precedence over the duration of the recurrence
> instance defined by the "DTSTART" property.

+1

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:16:31 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 6 Recommended Practices #3: Different TZID?

Hi Bernard,

--On November 5, 2006 5:35:01 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

>  > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
>  >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
>  >     "VTODO" calendar components, have the same value data type (e.g.,
>  >     DATE-TIME), they SHOULD specify values in the same time format
>  >     (e.g., UTC time format).
>
> What about DATE-TIME values with different TZID parameter values
> (e.g., airline flights, that start in one time zone and end in
> another)?  Obviously, I think this should be okay.

Yes - we must allow different TZID's on DTSTART/DTEND/DUE.

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:14:42 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <	DTSTART

Hi Bernard,

--On November 5, 2006 5:33:14 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>
>  > The "DTSTART" property defines the first instance in the
>  > recurrence set.
>
> I believe this section should clarify that the "RDATE" property
> value can actually be earlier in time than the value of the
> "DTSTART" property.

+1

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:13:54 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.3.1 Time Zone Identifier: Scope of TZID

Hi Bernard,

--On November 5, 2006 5:30:36 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> In section 4.8.3.1 Time Zone Identifier of RFC 2445 it says:
>
>  > Purpose: This property specifies the text value that uniquely
>  > identifies the "VTIMEZONE" calendar component.
>
> This section should specify the "scope" in which a TZID MUST be
> unique when the "TZID" property value does not start with a
> SOLIDUS character.
>
> I believe the "TZID" MUST be unique in the scope of an iCalendar
> object, but not in the context of an iCalendar stream...

Right - inside of a BEGIN/END VCALENDAR, TZID must be unqiue, but it does 
not need to be unique across all BEGIN/END VCALENDAR's in a stream. I guess 
we need to add text for this now that we are using 'object' and 'stream' 
terminology.

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:05:36 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.2 Property Parameters: ianaparam

Hi Bernard,

--On November 5, 2006 5:29:56 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> Section 4.2 Property Parameters of RFC 2445 defines a "ianaparam"
> rule in its ABNF, but while all the properties allow "xparam",
> none of them currently allow "ianaparam".
>
> Shouldn't all properties allow "ianaparam"? That is, parameters
> *not* defined in this specification, but registered to IANA.

Suggestion: use 'other-param' here and then define:

other-param = *(iana-param / x-param)

That will make the ABNF a little shorter.

You might also want to do the same for iana-prop/x-prop.

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:04:11 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE parameter

Hi Bernard,

--On November 5, 2006 5:29:25 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> RFC 2445 allows some properties of TEXT value type to be specified
> multiple times. In some cases (e.g., "TZNAME") it is specified that
> the property can be specified more than once for specifying multiple
> language variants of the property value.
>
> I think section 4.1.2 Multiple Values should clarify how the
> "LANGUAGE" parameter should be handled with multi-valued TEXT
> properties.
>
> For instance, in a "VJOURNAL" calendar component, can I have two
> "DESCRIPTION" with "LANGUAGE=en", but only one "DESCRIPTION" with
> "LANGUAGE=fr"?  If so, should my client only display the one in
> French, or should it display all three values?
>
> Currently, I think it should display all three values...

Its really not clear how multi-lingual 'alternatives' of an iCalendar 
component should be handled. The suggestion of using multiple properties 
with different LANGUAGES really does not work as there is no way to 
unambiguously tie the variants together as alternatives.

A better approach might be to say that language alternatives should be 
constructed at the MIME level - i.e. as separate components in separate 
MIME parts inside a multipart/alternative.

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 07:00:34 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE

Hi Bernard,

--On November 5, 2006 5:28:29 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> Proposed new text:
>
>  > The "VTIMEZONE" calendar component MUST be present if the calendar
>  > component contains an "RRULE" that generates recurrence instances on
>  > both sides of a time zone shift (e.g., both in Standard Time and
>  > Daylight Saving Time) unless the "DTSTART" property of the calendar
>  > component is specified as a DATE value or as a "floating" DATE-TIME
>  > value (See section 3.3.12 for proper interpretation of floating time).

Actually what is being said here is that a recurring event that uses a 
DATE-TIME value for DTSTART MUST either be floating or local time (i.e. 
timezone). Whether VTIMEZONE is present or not is then determined by the 
requirement of having it present if a DTSTART uses a TZID property. i.e. 
the RRULE does not drive the requirement for VTIMEZONE, instead the DTSTART 
does.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: DURATION when =?iso-8859-1?q?DTSTART=09is_a?= DATE
Date: Mon, 6 Nov 2006 16:00:48 +0100

Am Montag, 6. November 2006 15:44 schrieb Cyrus Daboo:
> Hi Bernard,
>
> --On November 5, 2006 5:25:58 PM -0500 Bernard Desruisseaux
>
> <[email-masked]> wrote:
> >  > The "VEVENT" is also the calendar component used to specify an
> >  > anniversary or daily reminder within a calendar. These events have a
> >  > DATE value type for the "DTSTART" property instead of the default
> >  > data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
> >  > MUST be specified as a DATE value also.
> >
> > I believe the text should also specify the following with respect
> >
> > to the DURATION property:
> >  > If such a "VEVENT" has a "DURATION" property, it MUST be specified
> >  > as a "dur-day" or "dur-week" values.
>
> +1

Completely agree, too.
The problem with rfc 2445 is inter alias that it only standardizes a syntax, 
but does not care about internal consistency of data. E.g. it was never 
explicitly forbidden to create an event with a DATE-TIME value for DTSTART 
and a DATE value for DTEND. Or an DATE value for DTSTART and a DATE-TIME 
value of RDATE (what should be the duration of that instance??) 

Looking at the archives, F. Dawson or M. Stenerson stated that it was 
understood that the types should match, but that the rfc never tried to 
enforce something like this. 

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Mon, 06 Nov 2006 06:57:31 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.3 Journal Component: DESCRIPTION property

Hi Bernard,

--On November 5, 2006 5:27:32 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

>  > jourprop   = *(
>  >
>  >            ; the following are optional,
>  >            ; but MUST NOT occur more than once
>  >
>  >            class / created / description / dtstart / dtstamp /
>  >            last-mod / organizer / recurid / seq / status /
>  >            summary / uid / url /
>
> But according to section 4.8.1.5 Description, the "DESCRIPTION"
> property can be specified multiple times within a "VJOURNAL"
> calendar component.
>
> As such, I propose to modify the "jourprop" rule in section
> 4.6.3 to be in accordance with the text in section 4.8.1.5.

+1

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 06:48:45 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Default duration of	day events

Hi Bernard,

--On November 5, 2006 5:26:48 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> In section 4.6.1 Event Component of RFC 2445 it says:
>
>  > For cases where a "VEVENT" calendar component specifies a "DTSTART"
>  > property with a DATE data type but no "DTEND" property, the events
>  > non-inclusive end is the end of the calendar date specified by the
>  > "DTSTART" property.
>
> As such, the last sentence of the paragraph before the following example
> is wrong. This event would actually appear as opaque in a search for busy
> time.
>
>  > The following is an example of the "VEVENT" calendar component used
>  > to represent an anniversary that will occur annually. Since it takes
>  > up no time, it will not appear as opaque in a search for busy time;
>  > no matter what the value of the "TRANSP" property indicates:
>  >
>  >   BEGIN:VEVENT
>  >   UID:[email-masked]
>  >   DTSTAMP:19970901T1300Z
>  >   DTSTART:19971102
>  >   SUMMARY:Our Blissful Anniversary
>  >   CLASS:CONFIDENTIAL
>  >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
>  >   RRULE:FREQ=YEARLY
>  >   END:VEVENT
>
> I propose to remove this sentence and to add the TRANSP property to
> the example.
>
> Proposed text:
>
>  > The following is an example of the "VEVENT" calendar component used
>  > to represent an anniversary that will occur annually.
>  >
>  >   BEGIN:VEVENT
>  >   UID:[email-masked]
>  >   DTSTAMP:19970901T1300Z
>  >   DTSTART:19971102
>  >   SUMMARY:Our Blissful Anniversary
>  >   TRANSP:TRANSPARENT
>  >   CLASS:CONFIDENTIAL
>  >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
>  >   RRULE:FREQ=YEARLY
>  >   END:VEVENT
>
> Similarly, in section 4.8.2.4 Date/Time Start of RFC 2445 it says:
>
>  > Description: Within the "VEVENT" calendar component, this property
>  > defines the start date and time for the event. The property is
>  > REQUIRED in "VEVENT" calendar components. Events can have a start
>  > date/time but no end date/time. In that case, the event does not take
>  > up any time.
>
> I propose to remove the last two sentences of this paragraph.
>
> Proposed text:
>
>  > Description: Within the "VEVENT" calendar component, this property
>  > defines the start date and time for the event. The property is
>  > REQUIRED in "VEVENT" calendar components.
>
> Finally, in section 6 Recommended Practices of RFC 2445 it says:
>
>  > 2.  A calendar entry with a "DTSTART" property but no "DTEND"
>  >     property does not take up any time. It is intended to represent
>  >     an event that is associated with a given calendar date and time
>  >     of day, such as an anniversary. Since the event does not take up
>  >     any time, it MUST NOT be used to record busy time no matter what
>  >     the value for the "TRANSP" property.
>
> This is actually wrong. I would simply remove this text. The proper
> behave is described in section 4.6.1 Event Component.

This issue begs the question of whether all day events should automatically 
appear as opaque in free-busy lookups. I suspect most implementations do 
not add TRANS:TRANSPARENT when adding an 'anniversary' event - but having 
that block out time would be bad.

This would be a change to 2445, but one solution is to say the default 
TRANSP for all day events is TRANSPARENT rather than OPAQUE.

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 06:44:56 -0800
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: DURATION when DTSTART	is a DATE

Hi Bernard,

--On November 5, 2006 5:25:58 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

>  > The "VEVENT" is also the calendar component used to specify an
>  > anniversary or daily reminder within a calendar. These events have a
>  > DATE value type for the "DTSTART" property instead of the default
>  > data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
>  > MUST be specified as a DATE value also.
>
> I believe the text should also specify the following with respect
> to the DURATION property:
>
>  > If such a "VEVENT" has a "DURATION" property, it MUST be specified
>  > as a "dur-day" or "dur-week" values.

+1

-- 
Cyrus Daboo

Date: Mon, 06 Nov 2006 09:00:37 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART
Cc: [email-masked]

Reinhold,

In my opinion we need to allow RDATE to be less than DTSTART,
even more so now that DTSTART should be synchronized with the
recurrence rule.

Let's say I want to have a meeting today (Monday) with three
further instances on the next upcoming Tuesday. I could easily
do that with an RDATE set to today (Monday) and a DTSTART set
to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.

Cheers,
Bernard

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>>  > The "DTSTART" property defines the first instance in the
>>  > recurrence set.
>>
>> I believe this section should clarify that the "RDATE" property
>> value can actually be earlier in time than the value of the
>> "DTSTART" property.
> 
> I always understood this sentence that the DTSTART is always the first 
> date/time of the event and RDATE cannot be earlier. Otherwise, to determine 
> whether an event happens today, one would have to look at all recurrences of 
> all events, future or past. If the DTSTART is always the first time, then it 
> suffices to look at all events that have already started at the given date 
> (i.e. DTSTART<=givenDateTime).
> 
> Cheers,
> Reinhold
> - -- 
> - ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: [email-masked], http://reinhold.kainhofer.com/
>  * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> 
> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6
> RUXtgVx4DX3mzyaAq+CT9j4=
> =5sgz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: "Tim Hare" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of an instance might change?
Date: Mon, 6 Nov 2006 08:35:10 -0500
From: "Robert Ransdell" <[email-masked]>
Cc: 'Calsify WG' <[email-masked]>, [email-masked]

--=_alternative 004A98DD8525721E_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

If  I remember correctly from those discussions, the only time the=20
RECURRENCE=5FID's can change, is when ORGANIZER changes the repeat rule for=
=20
the entire set.  I was part of that long heated discussion, so this will=20
be my only response/reminder of what was said.

"Tim Hare" <[email-masked]>=20
Sent by: [email-masked]
11/05/2006 06:16 PM

To
"'Calsify WG'" <[email-masked]>
cc

Subject
RE: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of an=20
instance might change?

=20
Before making any changes in the SEQUENCE/RECURRENCE-ID area, I would
suggest you thoroughly search the archives (for this WG and for the=20
previous
WG)  for the many lengthy (and sometimes heated) discussions about this=20
very
thing.  Who "owns" those archives? This subject has been so confusing that
it would be worthwhile to collect all of those messages into their own=20
space
somewhere.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Sunday, November 05, 2006 5:33 PM
To: Calsify WG
Subject: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of an
instance might change?

In section 4.8.4.4 Recurrence ID of RFC 2445 it says:

 > When the definition of the recurrence set for a calendar component  >
changes, and hence the "SEQUENCE" property value changes, the  >
"RECURRENCE-ID" for a given recurrence instance might also change.

How could one possibly correlate the specific recurrence instance for=20
which
the "RECURRENCE-ID" changed?

When the definition of the recurrence set for a calendar component=20
changes,
specific recurrence instances might be added or removed from the=20
recurrence
set.

I propose to remove the text mentioned above.

Cheers,
Bernard
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=_alternative 004A98DD8525721E_=
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<br><font size=3D2 face=3D"sans-serif">If &nbsp;I remember correctly from t=
hose
discussions, the only time the </font><tt><font size=3D2>RECURRENCE</font><=
/tt><font size=3D2 face=3D"sans-serif">=5FID's
can change, is when ORGANIZER changes the repeat rule for the entire set.
<i>&nbsp;</i>I was part of that long heated discussion, so this will be
my only response/reminder of what was said.</font><br><br><br><br><table wi=
dth=3D100%><tr valign=3Dtop><td width=3D40%><font size=3D1 face=3D"sans-ser=
if"><b>&quot;Tim Hare&quot; &lt;[email-masked]&gt;</b></font><br><font=
 size=3D1 face=3D"sans-serif">Sent by: [email-masked]=
rg</font><p><font size=3D1 face=3D"sans-serif">11/05/2006 06:16 PM</font><t=
d width=3D59%><table width=3D100%><tr valign=3Dtop><td><div align=3Dright><=
font size=3D1 face=3D"sans-serif">To</font></div><td><font size=3D1 face=3D=
"sans-serif">&quot;'Calsify WG'&quot; &lt;[email-masked]&gt=
;</font><tr valign=3Dtop><td><div align=3Dright><font size=3D1 face=3D"sans=
-serif">cc</font></div><td><tr valign=3Dtop><td><div align=3Dright><font si=
ze=3D1 face=3D"sans-serif">Subject</font></div><td><font size=3D1 face=3D"s=
ans-serif">RE: [Ietf-calsify] Section 4.8.4.4 Recurrence
ID: RECURRENCE-ID of an &nbsp; &nbsp; &nbsp; &nbsp;instance might
change?</font></table><br><table><tr valign=3Dtop><td><td></table><br></tab=
le><br><br><br><tt><font size=3D2>&nbsp;<br>Before making any changes in th=
e SEQUENCE/RECURRENCE-ID area, I would<br>suggest you thoroughly search the=
 archives (for this WG and for the previous<br>WG) &nbsp;for the many lengt=
hy (and sometimes heated) discussions about
this very<br>thing. &nbsp;Who &quot;owns&quot; those archives? This subject=
 has been
so confusing that<br>it would be worthwhile to collect all of those message=
s into their own
space<br>somewhere.<br><br>Tim Hare<br>Interested Bystander, Non-Inc.<br><b=
r>-----Original Message-----<br>From: [email-masked]=
g<br>[mailto:[email-masked]] On Behalf Of Bernard<b=
r>Desruisseaux<br>Sent: Sunday, November 05, 2006 5:33 PM<br>To: Calsify WG=
<br>Subject: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of
an<br>instance might change?<br><br>In section 4.8.4.4 Recurrence ID of RFC=
 2445 it says:<br><br> &gt; When the definition of the recurrence set for a=
 calendar component
&nbsp;&gt;<br>changes, and hence the &quot;SEQUENCE&quot; property value ch=
anges, the
&nbsp;&gt;<br>&quot;RECURRENCE-ID&quot; for a given recurrence instance mig=
ht also change.<br><br>How could one possibly correlate the specific recurr=
ence instance for which<br>the &quot;RECURRENCE-ID&quot; changed?<br><br>Wh=
en the definition of the recurrence set for a calendar component changes,<b=
r>specific recurrence instances might be added or removed from the recurren=
ce<br>set.<br><br>I propose to remove the text mentioned above.<br><br>Chee=
rs,<br>Bernard<br>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F<br>Ietf-calsify mailing list<br>[email-masked]<br=
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify<br><br><br>=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br>Ietf-=
calsify mailing list<br>[email-masked]<br>http://lists.osaf=
oundation.org/mailman/listinfo/ietf-calsify<br></font></tt><br><BR>
--=_alternative 004A98DD8525721E_=--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART
Date: Mon, 6 Nov 2006 09:40:37 +0100

Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>  > The "DTSTART" property defines the first instance in the
>  > recurrence set.
>
> I believe this section should clarify that the "RDATE" property
> value can actually be earlier in time than the value of the
> "DTSTART" property.

I always understood this sentence that the DTSTART is always the first 
date/time of the event and RDATE cannot be earlier. Otherwise, to determine 
whether an event happens today, one would have to look at all recurrences of 
all events, future or past. If the DTSTART is always the first time, then it 
suffices to look at all events that have already started at the given date 
(i.e. DTSTART<=givenDateTime).

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 6 Recommended Practices #3: Different TZID?
Date: Mon, 6 Nov 2006 09:40:26 +0100

Am Sonntag, 5. November 2006 23:35 schrieb Bernard Desruisseaux:
> In section 6 Recommended Practices of RFC 2445 it says:
>  > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
>  >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
>  >     "VTODO" calendar components, have the same value data type (e.g.,
>  >     DATE-TIME), they SHOULD specify values in the same time format
>  >     (e.g., UTC time format).
>
> What about DATE-TIME values with different TZID parameter values
> (e.g., airline flights, that start in one time zone and end in
> another)?  Obviously, I think this should be okay.

I also think that's okay with the formulation above, as long as both are given 
with TZID. What's not allowed is to have e.g. DTSTART in "Z"-notation and 
DTEND in floating or timezone notation.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Sun, 05 Nov 2006 18:53:01 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: Allowed forms for aDATE-TIME
Cc: 'Calsify WG' <[email-masked]>

Tim Hare wrote:
> Wait! Are you saying that recurrence rules cannot use "floating" date-time?

Humm.  I was.  On second thought, I realize that this needs to be possible.

> There's a very good use case for it: conference scheduling. There might be
> an "administrivia" meeting every morning of the conference week at the same
> time and place - a clear case for recurrence - yet, many attendees do not
> like to set their devices to the local time of the conference (unless the
> device changes to local time automatically as cell phones do) and so the
> conference schedule is published in "floating" time. 

I don't believe anybody should publish a conference schedule in "floating
time", but I agree that one might want to publish recurring floating
events such as "Lunch" or "Diner"...

Cheers,
Bernard

> 
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Bernard
> Desruisseaux
> Sent: Sunday, November 05, 2006 5:31 PM
> To: Calsify WG
> Subject: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: Allowed forms for
> aDATE-TIME
> 
> In section 4.8.4.4 Recurrence ID of RFC 2445 it says:
> 
>  > Value Type: The default value type for this property is DATE-TIME.
>  > The time format can be any of the valid forms defined for a DATE-TIME  >
> value type. See DATE-TIME value type definition for specific  >
> interpretations of the various forms. The value type can be set to  > DATE.
> 
> I don't believe it should be possible to specify a "RECURRENCE-ID"
> property with a "floating" date-time.
> 
> Proposed text:
> 
>  > Value Type: The default value type is DATE-TIME. The date-time
>  >    value MUST be either a date with UTC time, or a date with
>  >    local time and time zone reference. The value type can be
>  >    set to a DATE value type.
> 
> Cheers,
> Bernard
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of an instance might change?
Date: Sun, 5 Nov 2006 18:15:58 -0500

Before making any changes in the SEQUENCE/RECURRENCE-ID area, I would
suggest you thoroughly search the archives (for this WG and for the previous
WG)  for the many lengthy (and sometimes heated) discussions about this very
thing.  Who "owns" those archives? This subject has been so confusing that
it would be worthwhile to collect all of those messages into their own space
somewhere.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Sunday, November 05, 2006 5:33 PM
To: Calsify WG
Subject: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of an
instance might change?

In section 4.8.4.4 Recurrence ID of RFC 2445 it says:

 > When the definition of the recurrence set for a calendar component  >
changes, and hence the "SEQUENCE" property value changes, the  >
"RECURRENCE-ID" for a given recurrence instance might also change.

How could one possibly correlate the specific recurrence instance for which
the "RECURRENCE-ID" changed?

When the definition of the recurrence set for a calendar component changes,
specific recurrence instances might be added or removed from the recurrence
set.

I propose to remove the text mentioned above.

Cheers,
Bernard
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: Allowed forms for aDATE-TIME
Date: Sun, 5 Nov 2006 18:13:12 -0500

Wait! Are you saying that recurrence rules cannot use "floating" date-time?
There's a very good use case for it: conference scheduling. There might be
an "administrivia" meeting every morning of the conference week at the same
time and place - a clear case for recurrence - yet, many attendees do not
like to set their devices to the local time of the conference (unless the
device changes to local time automatically as cell phones do) and so the
conference schedule is published in "floating" time. 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Sunday, November 05, 2006 5:31 PM
To: Calsify WG
Subject: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: Allowed forms for
aDATE-TIME

In section 4.8.4.4 Recurrence ID of RFC 2445 it says:

 > Value Type: The default value type for this property is DATE-TIME.
 > The time format can be any of the valid forms defined for a DATE-TIME  >
value type. See DATE-TIME value type definition for specific  >
interpretations of the various forms. The value type can be set to  > DATE.

I don't believe it should be possible to specify a "RECURRENCE-ID"
property with a "floating" date-time.

Proposed text:

 > Value Type: The default value type is DATE-TIME. The date-time
 >    value MUST be either a date with UTC time, or a date with
 >    local time and time zone reference. The value type can be
 >    set to a DATE value type.

Cheers,
Bernard
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Sun, 05 Nov 2006 17:35:33 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 6 Recommended Practices #4: Precedence of duration of RDATE

In section 6 Recommended Practices of RFC 2445 it says:

 > 4.  When the combination of the "RRULE" and "RDATE" properties on an
 >     iCalendar object produces multiple instances having the same
 >     start date/time, they should be collapsed to, and considered as,
 >     a single instance.

We should probably clarify that if the "RDATE" property is specified as
a PERIOD, its duration has precedence over the duration of the recurrence
instance defined by the "DTSTART" property.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:36:05 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.2.5 Duration: VFREEBUSY request

In section 4.8.2.5 Duration of RFC 2445 it says:

 > In a "VFREEBUSY" calendar component the property may be
 > used to specify the interval of free time being requested.

Yet, section 3.3.2 REQUEST of RFC 2446 (iTIP) specifies that
the DURATION property is not allowed in a VFREEBUSY request.

I see three options:

a) Remove statement from iCalendar to be in sync with iTIP;

b) Change iTIP to allow the DURATION property in a VFREEBUSY
    request and define the semantic as specified in iCalendar.

c) Status quo.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:35:01 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 6 Recommended Practices #3: Different TZID?

In section 6 Recommended Practices of RFC 2445 it says:

 > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
 >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
 >     "VTODO" calendar components, have the same value data type (e.g.,
 >     DATE-TIME), they SHOULD specify values in the same time format
 >     (e.g., UTC time format).

What about DATE-TIME values with different TZID parameter values
(e.g., airline flights, that start in one time zone and end in
another)?  Obviously, I think this should be okay.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:33:14 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART

In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:

 > The "DTSTART" property defines the first instance in the
 > recurrence set.

I believe this section should clarify that the "RDATE" property
value can actually be earlier in time than the value of the
"DTSTART" property.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:33:51 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.8.2 Request Status: 3-tuples or pairs?

In Section 4.8.8.2 Request Status of RFC 2445 it says:

 > The short return status is a PERIOD character (US-ASCII decimal 46)
 > separated 3-tuple of integers. For example, "3.1.1". The successive
 > levels of integers provide for a successive level of status code
 > granularity.

But all the examples in the draft specify REQUEST-STATUS values with
only a pair of integers (e.g., "2.0").

Furthermore, all the values specified in section 3.6 Status Replies of
RFC 2246 are only pair of integers.

I see two options:

a) Change text to allow pairs and 3-tuples;

b) Change text to allow pairs only.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:32:44 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of an instance might change?

In section 4.8.4.4 Recurrence ID of RFC 2445 it says:

 > When the definition of the recurrence set for a calendar component
 > changes, and hence the "SEQUENCE" property value changes, the
 > "RECURRENCE-ID" for a given recurrence instance might also change.

How could one possibly correlate the specific recurrence instance
for which the "RECURRENCE-ID" changed?

When the definition of the recurrence set for a calendar component
changes, specific recurrence instances might be added or removed
from the recurrence set.

I propose to remove the text mentioned above.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:30:36 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.3.1 Time Zone Identifier: Scope of TZID

In section 4.8.3.1 Time Zone Identifier of RFC 2445 it says:

 > Purpose: This property specifies the text value that uniquely
 > identifies the "VTIMEZONE" calendar component.

This section should specify the "scope" in which a TZID MUST be
unique when the "TZID" property value does not start with a
SOLIDUS character.

I believe the "TZID" MUST be unique in the scope of an iCalendar
object, but not in the context of an iCalendar stream...

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:31:27 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.4.4 Recurrence ID: Allowed forms for a DATE-TIME

In section 4.8.4.4 Recurrence ID of RFC 2445 it says:

 > Value Type: The default value type for this property is DATE-TIME.
 > The time format can be any of the valid forms defined for a DATE-TIME
 > value type. See DATE-TIME value type definition for specific
 > interpretations of the various forms. The value type can be set to
 > DATE.

I don't believe it should be possible to specify a "RECURRENCE-ID"
property with a "floating" date-time.

Proposed text:

 > Value Type: The default value type is DATE-TIME. The date-time
 >    value MUST be either a date with UTC time, or a date with
 >    local time and time zone reference. The value type can be
 >    set to a DATE value type.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:29:56 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.2 Property Parameters: ianaparam

Section 4.2 Property Parameters of RFC 2445 defines a "ianaparam"
rule in its ABNF, but while all the properties allow "xparam",
none of them currently allow "ianaparam".

Shouldn't all properties allow "ianaparam"? That is, parameters
*not* defined in this specification, but registered to IANA.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:29:25 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE parameter

RFC 2445 allows some properties of TEXT value type to be specified
multiple times. In some cases (e.g., "TZNAME") it is specified that
the property can be specified more than once for specifying multiple
language variants of the property value.

I think section 4.1.2 Multiple Values should clarify how the
"LANGUAGE" parameter should be handled with multi-valued TEXT
properties.

For instance, in a "VJOURNAL" calendar component, can I have two
"DESCRIPTION" with "LANGUAGE=en", but only one "DESCRIPTION" with
"LANGUAGE=fr"?  If so, should my client only display the one in
French, or should it display all three values?

Currently, I think it should display all three values...

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:28:29 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE

In section 4.6.5 Time Zone Component of RFC 2445 it says:

 > The "VTIMEZONE" calendar component MUST be present if the iCalendar
 > object contains an RRULE that generates dates on both sides of a time
 > zone shift (e.g. both in Standard Time and Daylight Saving Time)
 > unless the iCalendar object intends to convey a floating time (See
 > the section "4.1.10.11 Time" for proper interpretation of floating
 > time).

I believe the text should further clarify that a "VTIMEZONE"
calendar component is not required when the calendar component
has a DATE value type for the "DTSTART" property.

Proposed new text:

 > The "VTIMEZONE" calendar component MUST be present if the calendar
 > component contains an "RRULE" that generates recurrence instances on
 > both sides of a time zone shift (e.g., both in Standard Time and
 > Daylight Saving Time) unless the "DTSTART" property of the calendar
 > component is specified as a DATE value or as a "floating" DATE-TIME
 > value (See section 3.3.12 for proper interpretation of floating time).

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:27:32 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.3 Journal Component: DESCRIPTION property

In section 4.6.3 Journal Component of RFC 2445 it says:

 > jourprop   = *(
 >
 >            ; the following are optional,
 >            ; but MUST NOT occur more than once
 >
 >            class / created / description / dtstart / dtstamp /
 >            last-mod / organizer / recurid / seq / status /
 >            summary / uid / url /

But according to section 4.8.1.5 Description, the "DESCRIPTION"
property can be specified multiple times within a "VJOURNAL"
calendar component.

As such, I propose to modify the "jourprop" rule in section
4.6.3 to be in accordance with the text in section 4.8.1.5.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:26:48 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.1 Event Component: Default duration of day events

In section 4.6.1 Event Component of RFC 2445 it says:

 > For cases where a "VEVENT" calendar component specifies a "DTSTART"
 > property with a DATE data type but no "DTEND" property, the events
 > non-inclusive end is the end of the calendar date specified by the
 > "DTSTART" property.

As such, the last sentence of the paragraph before the following example
is wrong. This event would actually appear as opaque in a search for busy
time.

 > The following is an example of the "VEVENT" calendar component used
 > to represent an anniversary that will occur annually. Since it takes
 > up no time, it will not appear as opaque in a search for busy time;
 > no matter what the value of the "TRANSP" property indicates:
 >
 >   BEGIN:VEVENT
 >   UID:[email-masked]
 >   DTSTAMP:19970901T1300Z
 >   DTSTART:19971102
 >   SUMMARY:Our Blissful Anniversary
 >   CLASS:CONFIDENTIAL
 >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
 >   RRULE:FREQ=YEARLY
 >   END:VEVENT

I propose to remove this sentence and to add the TRANSP property to
the example.

Proposed text:

 > The following is an example of the "VEVENT" calendar component used
 > to represent an anniversary that will occur annually.
 >
 >   BEGIN:VEVENT
 >   UID:[email-masked]
 >   DTSTAMP:19970901T1300Z
 >   DTSTART:19971102
 >   SUMMARY:Our Blissful Anniversary
 >   TRANSP:TRANSPARENT
 >   CLASS:CONFIDENTIAL
 >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
 >   RRULE:FREQ=YEARLY
 >   END:VEVENT

Similarly, in section 4.8.2.4 Date/Time Start of RFC 2445 it says:

 > Description: Within the "VEVENT" calendar component, this property
 > defines the start date and time for the event. The property is
 > REQUIRED in "VEVENT" calendar components. Events can have a start
 > date/time but no end date/time. In that case, the event does not take
 > up any time.

I propose to remove the last two sentences of this paragraph.

Proposed text:

 > Description: Within the "VEVENT" calendar component, this property
 > defines the start date and time for the event. The property is
 > REQUIRED in "VEVENT" calendar components.

Finally, in section 6 Recommended Practices of RFC 2445 it says:

 > 2.  A calendar entry with a "DTSTART" property but no "DTEND"
 >     property does not take up any time. It is intended to represent
 >     an event that is associated with a given calendar date and time
 >     of day, such as an anniversary. Since the event does not take up
 >     any time, it MUST NOT be used to record busy time no matter what
 >     the value for the "TRANSP" property.

This is actually wrong. I would simply remove this text. The proper
behave is described in section 4.6.1 Event Component.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:25:58 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.1 Event Component: DURATION when DTSTART is a DATE

In section 4.6.1 Event Component of RFC 2445 it says:

 > The "VEVENT" is also the calendar component used to specify an
 > anniversary or daily reminder within a calendar. These events have a
 > DATE value type for the "DTSTART" property instead of the default
 > data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
 > MUST be specified as a DATE value also.

I believe the text should also specify the following with respect
to the DURATION property:

 > If such a "VEVENT" has a "DURATION" property, it MUST be specified
 > as a "dur-day" or "dur-week" values.

Cheers,
Bernard

Date: Sun, 05 Nov 2006 17:24:33 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.3.10 Recurrence Rule: Order of rule parts

In section 4.3.10 Recurrence Rule of RFC 2445 it says:

 > The rule parts are not ordered in any particular sequence.

On the other hand, the way the ABNF of the "recur" rule is
written, the "FREQ" rule should always appear first.

I'm not sure how the "recur" rule should be rewritten.
Any help appreciated...

Cheers,
Bernard