Subject: [Ietf-calsify] Proposed text for DST and leap-second discontinuities

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Thu May 31 12:04:14 2007

Here's some proposed text for the DST and leap-second discontinuities.  I
think this reflects the consensus that got hammered out in Prague and in the
Jabber sessions.

In section 3.3.5. (Date-Time), at the end of Form #3 (DATE WITH LOCAL TIME
AND TIME ZONE REFERENCE), before the example of all three forms:

    If, based on the definition of the referenced time zone, the local time
    described occurs more than once (due to clocks being set back), the
    DATE-TIME value refers to the first occurence of the referenced time.
    Thus, TZID=America/New_York:20071104T013000 indicates November 4, 2007
    at 1:30 AM EDT (UTC-4).  If the local time described does not occur (due
    to clocks being set forward), the DATE-TIME value is interpreted using
    the UTC offset before the gap in local times.  Thus,
    TZID=America/New_York:20070311T023000 indicates March 11, 2007 at 3:30
    AM EDT (UTC-4), one hour after 1:30 AM EST (UTC-5).

At the end of 3.3.5, after the leap-second text:

   Implementations which do not support leap seconds SHOULD interpret "60"
   in the seconds field as equivalent to "59".

(Editorial: the leap-second text should move up into the "Description"
section; it's in the "Example" section in 2445bis-06.)

In section 3.3.6 (Duration), at the end of the "Description" section:

   Hours, minutes, and seconds are "exact" durations: they indicate an
   actual amount of time elapsed, regardless of local time zone changes in
   UTC offsets.  Thus, a duration of PT24H beginning at
   TZID=America/New_York:20071103T090000 (November 3, 2007 9:00:00 AM EDT)
   ends at November 4, 2007 8:00:00 AM EST, 24 hours later.  As an exception,
   however, durations are always calculated assuming minutes have exactly 60
   seconds, ignoring leap seconds.

   Weeks and days are "nominal" durations: when durations are calculated
   based on times with time zone references, they indicate a period of time
   with the date field adjusted and the time-of-day unchanged, even when the
   local time's UTC offset changes.  Thus, a duration of P1D beginning at
   TZID=America/New_York:20071103T090000 (November 3, 2007 9:00:00 AM EDT)
   ends at November 4, 2007 9:00:00 AM EST, 25 hours later.

   If the local time when a nominal duration would end does not exist, or
   occurs more than once, in the duration's timezone, it is interpreted in
   the same manner as an explicit DATE-TIME value describing that date and
   time, as specified in section 3.3.5.

   For durations which include both nominal and exact parts, the nominal
   component is resolved, and adjusted as necessary for for non-existant or
   duplicate times, before the exact component is applied.

In section 3.3.10 (Recurrence Rule), before the last paragraph in the
Description section:

   If the local time of a member of a generated recurrence set does not
   exist, or occurs more than once, in the event's timezone, the time
   of the member is interpreted in the same manner as an explicit DATE-TIME
   value describing that date and time, as specified in section 3.3.5.

In section 3.8.5.3 (Recurrence Rule), replace the text:

      If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.  Else, if the
      duration of the recurring component is specified with the
      "DURATION" property, then the same nominal duration will apply to
      all the members of the generated recurrence set and the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs.

with:

      If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the time between the event's "DTSTART"
      and "DTEND" or "DUE" is interpreted as an exact duration (ignoring
      leap seconds), and the same exact duration applies to all the members
      of the generated recurrence set.  Else, if the duration of the
      recurring component is specified with the "DURATION" property, then
      the same nominal and/or exact duration applies to all the members of the
      generated recurrence set.  If the duration includes a nominal
      component (days or weeks), the exact duration of each recurrence
      instance will depend on its specific start time.  For example,
      recurrence instances with a nominal duration of P1D will last for
      more or less than 24 hours on a day where a time zone shift occurs.

-- 
Jonathan Lennox
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Thu, 31 May 2007 15:02:46 -0400
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Proposed text for DST and leap-second discontinuities

Here's some proposed text for the DST and leap-second discontinuities.  I
think this reflects the consensus that got hammered out in Prague and in the
Jabber sessions.

In section 3.3.5. (Date-Time), at the end of Form #3 (DATE WITH LOCAL TIME
AND TIME ZONE REFERENCE), before the example of all three forms:

    If, based on the definition of the referenced time zone, the local time
    described occurs more than once (due to clocks being set back), the
    DATE-TIME value refers to the first occurence of the referenced time.
    Thus, TZID=America/New_York:20071104T013000 indicates November 4, 2007
    at 1:30 AM EDT (UTC-4).  If the local time described does not occur (due
    to clocks being set forward), the DATE-TIME value is interpreted using
    the UTC offset before the gap in local times.  Thus,
    TZID=America/New_York:20070311T023000 indicates March 11, 2007 at 3:30
    AM EDT (UTC-4), one hour after 1:30 AM EST (UTC-5).

At the end of 3.3.5, after the leap-second text:

   Implementations which do not support leap seconds SHOULD interpret "60"
   in the seconds field as equivalent to "59".

(Editorial: the leap-second text should move up into the "Description"
section; it's in the "Example" section in 2445bis-06.)

In section 3.3.6 (Duration), at the end of the "Description" section:

   Hours, minutes, and seconds are "exact" durations: they indicate an
   actual amount of time elapsed, regardless of local time zone changes in
   UTC offsets.  Thus, a duration of PT24H beginning at
   TZID=America/New_York:20071103T090000 (November 3, 2007 9:00:00 AM EDT)
   ends at November 4, 2007 8:00:00 AM EST, 24 hours later.  As an exception,
   however, durations are always calculated assuming minutes have exactly 60
   seconds, ignoring leap seconds.

   Weeks and days are "nominal" durations: when durations are calculated
   based on times with time zone references, they indicate a period of time
   with the date field adjusted and the time-of-day unchanged, even when the
   local time's UTC offset changes.  Thus, a duration of P1D beginning at
   TZID=America/New_York:20071103T090000 (November 3, 2007 9:00:00 AM EDT)
   ends at November 4, 2007 9:00:00 AM EST, 25 hours later.

   If the local time when a nominal duration would end does not exist, or
   occurs more than once, in the duration's timezone, it is interpreted in
   the same manner as an explicit DATE-TIME value describing that date and
   time, as specified in section 3.3.5.

   For durations which include both nominal and exact parts, the nominal
   component is resolved, and adjusted as necessary for for non-existant or
   duplicate times, before the exact component is applied.

In section 3.3.10 (Recurrence Rule), before the last paragraph in the
Description section:

   If the local time of a member of a generated recurrence set does not
   exist, or occurs more than once, in the event's timezone, the time
   of the member is interpreted in the same manner as an explicit DATE-TIME
   value describing that date and time, as specified in section 3.3.5.

In section 3.8.5.3 (Recurrence Rule), replace the text:

      If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.  Else, if the
      duration of the recurring component is specified with the
      "DURATION" property, then the same nominal duration will apply to
      all the members of the generated recurrence set and the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs.

with:

      If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the time between the event's "DTSTART"
      and "DTEND" or "DUE" is interpreted as an exact duration (ignoring
      leap seconds), and the same exact duration applies to all the members
      of the generated recurrence set.  Else, if the duration of the
      recurring component is specified with the "DURATION" property, then
      the same nominal and/or exact duration applies to all the members of the
      generated recurrence set.  If the duration includes a nominal
      component (days or weeks), the exact duration of each recurrence
      instance will depend on its specific start time.  For example,
      recurrence instances with a nominal duration of P1D will last for
      more or less than 24 hours on a day where a time zone shift occurs.

-- 
Jonathan Lennox
[email-masked]

Date: Thu, 31 May 2007 15:51:25 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts in 10 minutes

[email-masked].

Eliot

Date: Wed, 30 May 2007 21:13:18 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Imprecise and alternative events

Dear all,

This is to announce the new internet-draft:

<http://www.ietf.org/internet-drafts/draft-silva-events-00.txt>

It describes extensions for iCalendar and iTIP that allow the
expression of an event by grouping multiple alternatives that could
effectively be scheduled. A possible event can, in turn, be described
imprecisely, in terms of ranked time periods in which it might happen.

These features are specially useful during scheduling negotiation,
when several event options can be under consideration at a same time
and incomplete knowledge about possible events must be represented.

Whereas the draft proposes two new calendar components to accomplish
these features, it also discusses some drawbacks of such approach and
points possible paths for using the VEVENT component itself to do so.

Any comments you may have are welcome!

Cheers,

F=E1bio Silva.

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 79ed4edf0b637cf52767927fb2fea571
X-Spam-Score-Summary: 2, 0, 0, 50c04bb1ea637d71, 882bb7ff92202fa1, [email-masked], , RULES_HIT:1:2:69:355:379:539:540:541:542:543:567:599:601:945:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1587:1593:1594:1605:1730:1747:1766:1792:2073:2075:2078:2198:2199:2379:2393:2534:2551:2553:2559:2562:2692:2693:2731:2828:2911:3027:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4052:4250:4425:4605:5007:6117:6119, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Ietf-calsify] Proposal for issue 11
Date: Tue, 29 May 2007 21:54:16 +0100

> The proposal to close this is to add the attached table on recurrence =
part=20
> behavior to the draft. Plus there would be some text revisions to =
reference=20
> the table at appropriate places.
>=20
> Please review the attached table - Bernard will likely be adding it to =
the=20
> draft for the next revision.

I found the table very useful in explaining the whole Limit/Expand =
nature of the modifiers, but found all the notes on BYDAY very complex =
and discouraging.  I also finally got round to reading Claudio's =
comments, and of the 4, thought he only had one lengthy/major one, which =
related to the complexity of BYXX processing.  While adding the table =
will help, on closer inspection I think I've found inconsistencies when =
read with the spec that have led to the following comments:=20

- Note 1 implies that a numeric value is not allowed if the FREQ is =
WEEKLY, whereas it is currently left very vague in the spec.  If this is =
to be true, then it should be dissallowed for =
SECONDLY/MINUTELY/HOURLY/DAILY too and stated explicitly in the spec.  =
The alternative is we just ignore the numeric value should the interval =
be a week or less, but I think it's better to dissallow.  I suggest:

      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)
+      negative (-n) integer modifer.  These are only valid for MONTHLY
+      or YEARLY rules.  When present, they indicates the nth
+      occurrence of the specific day within the month or year.
+      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.

- In Note 3 it says the numeric value might be an offset into the month =
or the year.  I think this is an unhelpful, unintuative special case =
that contradicts the spec, and would rather the numeric value in a =
YEARLY rule is always the offset within the year.

- In Note 2 it implies that MONTHLY + BYDAY + BYYEARDAY needs to be =
considered, but in the MONTHLY + BYYEARDAY entry in the table it says =
N/A.   In fact it says that BYYEARDAY is only valid with YEARLY rules =
when no such restriction exists in the spec.  I think it's a helpful =
restriction to reduce complexity and ambiguity, but wouldn't go so far =
as to disallow with SECONDLY/MINUTELY/HOURLY/DAILY/WEEKLY, so I suggest:

      The BYYEARDAY rule part specifies a COMMA character (US-ASCII
      decimal 44) separated list of days of the year.  Valid values are
      1 to 366 or -366 to -1.  For example, -1 represents the last day
      of the year (December 31st) and -306 represents the 306th to the
-      last day of the year (March 1st).
+      last day of the year (March 1st).  This rule part is not valid
+      for WEEKLY or MONTHLY rules.

- The table implies WEEKLY + BYMONTHDAY is not allowed, but this isn't =
in the spec.  I think this is a helpful restriction, as either you are =
taking a month based view of life or a week based view of life, and the =
restriction reduces complexity and ambiguity.  I suggest the restriction =
is added by:

      The BYMONTHDAY rule part specifies a COMMA character (US-ASCII
      decimal 44) separated list of days of the month.  Valid values are
      1 to 31 or -31 to -1.  For example, -10 represents the tenth to
-      the last day of the month.
+      the last day of the month.  This rule part is not valid for =
WEEKLY rules.

- The table implies that BYWEEKNO can be used with =
SECONDLY/MINUTELY/HOURLY/DAILY/WEEKLY and the result is to limit, but =
the spec says about BYWEEKNO "This rule part is only valid for YEARLY =
rules.".   I suggest either we loosen the restriction on BYWEEKNO to =
permit it's use with SECONDLY/MINUTELY/HOURLY/DAILY/WEEKLY or else we =
correct the table.  For consistency with BYMONTHDAY, I suggest we loosen =
the spec, but dissallow with MONTHLY rules, as I think you either have a =
month based view of life or a week based view of life, and the =
restriction reduces complexity and ambiguity.  I suggest:

      The BYWEEKNO rule part specifies a COMMA character (US-ASCII
      decimal 44) separated list of ordinals specifying weeks of the
      year.  Valid values are 1 to 53 or -53 to -1.  This corresponds to
      weeks according to week numbering as defined in [ISO.8601.1988].
      A week is defined as a seven day period, starting on the day of
      the week defined to be the week start (see WKST).  Week number one
      of the calendar year is the first week which contains at least
-      four (4) days in that calendar year.  This rule part is only =
valid
-      for YEARLY rules.  For example, 3 represents the third week of =
the
+      four (4) days in that calendar year.  This rule part is not valid
+      for MONTHLY rules.  For example, 3 represents the third week of =
the
      year.

- Note 2 and 3 say that BYDAY with BYMONTHDAY/BYYEARDAY is Limit, but in =
the case below the total result would be Expand:

FREQ=3DMONTHLY;BYDAY=3DMO;BYMONTHDAY=3D1,2,3,4,5,6,7,8,9,10,11,12,13,14

I can see that the BYMONTHDAY/BYYEARDAY are applied first and Expand, =
and then BYDAY goes on to Limit, whereas the BYDAY on it's own would =
Expand, but the notes make this a bit labourious.  I think what we are =
trying to say is that BYMONTH/BYWEEKNO/BYMONTHDAY/BYYEARDAY/BYDAY all =
create an expansion set, but when used together it is the union of all =
sets that is used.  I suggest we amalgamate the processing of them all, =
illustrate this in the table and add this text:

      If multiple BYxxx rule parts are specified, then after evaluating
      the specified FREQ and INTERVAL rule parts, the BYxxx rule parts
      are applied to the current set of evaluated occurrences in the
      following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
      BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are
      evaluated.

+      A particular BYxxx rule part may expand or limit the set of =
date/times=20
+      generated by the rule. The expand or limit behaviour is governed =
by the=20
+      FREQ value used for the rule.
+
+   Example: =20
+        RRULE:FREQ=3DMONTHLY;BYMONTH=3D1,3,5;BYDAY=3DMO,TU
+
+      - The FREQ=3DMONTHLY value would match each of the twelve months=20
+        in a year.
+      - The BYMONTH=3D1,3,5 rule part limits the matching months to =
just=20
+        the 1st, 3rd and 5th in a year.
+      - The BYDAY=3DMO,TU rule part adds each Monday and Tuesday within =

+        the matching months to the recurrence set.
+
+      The table below shows the dependency of BYxxx rule part expand or =
limit=20
+      behaviour on the FREQ value in the rule. When evaluating a rule, =
each BYxxx=20
+      rule part must be evaluated in the order it appears in the table =
(i.e.=20
+      BYMONTH evaluated before BYWEEKNO), irrespective of the expand or =
limit=20
+      behaviour.
+
+      =
+------------------------------------------------------------------------=
----+
+      |            |SECONDLY|MINUTELY| HOURLY | DAILY  | WEEKLY | =
MONTHLY | YEARLY |
+      =
|------------+--------+--------+--------+--------+--------+---------+----=
----|
+      |BYMONTH     | Limit  | Limit  | Limit  | Limit  | Limit  | Limit =
  |        |
+      =
|------------+--------+--------+--------+--------+--------+---------+    =
    |
+      |BYWEEKNO    | Limit  | Limit  | Limit  | Limit  | Limit  | N/A   =
  |        |
+      =
|------------+--------+--------+--------+--------+--------+---------+    =
    |
+      |BYYEARDAY   | Limit  | Limit  | Limit  | Limit  | N/A    | N/A   =
  | Expand |
+      =
|------------+--------+--------+--------+--------+--------+---------+    =
    |
+      |BYMONTHDAY  | Limit  | Limit  | Limit  | Limit  | N/A    |       =
  |        |
+      |------------+--------+--------+--------+--------+--------+ =
Expand  +        |
+      |BYDAY       | Limit  | Limit  | Limit  | Limit  | Expand |       =
  |        |
+      =
|------------+--------+--------+--------+--------+--------+---------+----=
----|
+      |BYHOUR      | Limit  | Limit  | Limit  | Expand | Expand | =
Expand  | Expand |
+      =
|------------+--------+--------+--------+--------+--------+---------+----=
----|
+      |BYMINUTE    | Limit  | Limit  | Expand | Expand | Expand | =
Expand  | Expand |
+      =
|------------+--------+--------+--------+--------+--------+---------+----=
----|
+      |BYSECOND    | Limit  | Expand | Expand | Expand | Expand | =
Expand  | Expand |
+      =
|------------+--------+--------+--------+--------+--------+---------+----=
----|
+      |BYSETPOS    | Limit  | Limit  | Limit  | Limit  | Limit  | Limit =
  | Limit  |
+      =
|------------+--------+--------+--------+--------+--------+---------+----=
----|
+
+      In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and =
BYDAY work=20
+      together to expand the recurrence set.  Each on their own will =
specify
+      a range of valid instances, and when used in combination it is =
the union
+      of all ranges that create the required recurrence set.  So for =
example
+      in a YEARLY rule BYDAY=3DMO will mean every Monday, and =
BYMONTHDAY=3D1 will=20
+      mean the first of every month, so when used together they mean =
the first of=20
+      every month, but only when it's a Monday.  It would not mean on =
the first=20
+      of every month and also on every Monday.  Likewise in MONTHLY =
rules,=20
+      BYMONTHDAY and BYDAY work together to expand the recurrence set.

I think the above also explains the whole "special expand for =
weekly/monthly/yearly" concept which was another concept to understand =
and get wrong.

Nigel

Date: Sun, 27 May 2007 09:55:32 -0400
From: Cyrus Daboo <[email-masked]>
To: Ben Fortuna <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Re: RFC2445bis: Anniversary-style dates

Hi Ben,

--On May 27, 2007 5:52:44 PM +1000 Ben Fortuna <[email-masked]> wrote:

> Ok, I've just discovered there has been plenty of discussion on this
> topic, courtesy of the Bedework wiki:
>
> http://www.bedework.org/trac/bedework/wiki/Bedework/DevDocs/DtstartEndNot
> es
>
> Looks like the assumption is that DATE-based DTSTART/DTEND properties
> start at midnight, and have a duration of 23:59:59 hours (i.e.
> exclusive of midnight the next day). I'm not sure if this can be
> further clarified in the draft spec, but I think there is still
> potential for misinterpretation in it's current form.

Strictly speaking the duration is 24 hours not 23:59:59.

The spec is already pretty clear that DTEND represents the exclusive end of 
the time period, and I think that is implicit in the description of 
DTSTART;VALUE=DATE with a DTEND (or DURATION).

For VALUE=DATE, the proper "timed" interpretation is that of a floating 
time event set to start at 00:00:00 on the start date (inclusive) and end 
at 00:00:00 on the end date (exclusive).

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Date: Sun, 27 May 2007 12:42:26 +0200

Am Sonntag, 27. Mai 2007 schrieb Cyrus Daboo:
> What's more, URL is
> only allowed once in any VEVENT, so if you wanted to put links to multiple
> items, you would have to use description anyhow.

We use the ATTACH property for 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: Sun, 27 May 2007 17:52:44 +1000
From: "Ben Fortuna" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: RFC2445bis: Anniversary-style dates

Ok, I've just discovered there has been plenty of discussion on this
topic, courtesy of the Bedework wiki:

http://www.bedework.org/trac/bedework/wiki/Bedework/DevDocs/DtstartEndNotes

Looks like the assumption is that DATE-based DTSTART/DTEND properties
start at midnight, and have a duration of 23:59:59 hours (i.e.
exclusive of midnight the next day). I'm not sure if this can be
further clarified in the draft spec, but I think there is still
potential for misinterpretation in it's current form.

regards,
ben

On 5/27/07, Ben Fortuna <[email-masked]> wrote:
> Hi all,
>
> Apologies if this is off-topic, too late, or just plain painful to
> discuss (!), but I've noticed in the draft specification that
> anniversary-style dates (i.e. events containing DTSTART with
> VALUE=DATE and no DTEND or DURATION), are now assumed to have a
> duration of one (1) day as follows (3.6.1):
>
>       For cases where a "VEVENT" calendar component
>       specifies a "DTSTART" property with a DATE value type but no
>       "DTEND" nor DURATION property, the event's duration is taken to be
>       one day.
>
> Is there an assumption also being made as to the time that this
> duration starts? I ask this because the representation of a period of
> time requires the start (and end) of the period to be specified as a
> DATE-TIME component (3.3.9):
>
>         period     = period-explicit / period-start
>
>         period-explicit = date-time "/" date-time
>         ; [ISO.8601.1988] complete representation basic format for a
>         ; period of time consisting of a start and end. The start MUST
>         ; be before the end.
>
>         period-start = date-time "/" dur-value
>         ; [ISO.8601.1988] complete representation basic format for a
>         ; period of time consisting of a start and positive duration
>
> So if anniversary-style dates now have a default duration, but no
> specific time for the start of the duration, I still see a problem
> with how to represent that event's time consumption using a period of
> time. I think this is also an issue for events that do specify a
> DTEND, but both DTEND and DTSTART have VALUE=DATE.
>
> Thanks for any clarification of this issue.
>
> regards,
> ben
>

Date: Sun, 27 May 2007 15:59:52 +1000
From: "Ben Fortuna" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] RFC2445bis: Anniversary-style dates

Hi all,

Apologies if this is off-topic, too late, or just plain painful to
discuss (!), but I've noticed in the draft specification that
anniversary-style dates (i.e. events containing DTSTART with
VALUE=DATE and no DTEND or DURATION), are now assumed to have a
duration of one (1) day as follows (3.6.1):

      For cases where a "VEVENT" calendar component
      specifies a "DTSTART" property with a DATE value type but no
      "DTEND" nor DURATION property, the event's duration is taken to be
      one day.

Is there an assumption also being made as to the time that this
duration starts? I ask this because the representation of a period of
time requires the start (and end) of the period to be specified as a
DATE-TIME component (3.3.9):

        period     = period-explicit / period-start

        period-explicit = date-time "/" date-time
        ; [ISO.8601.1988] complete representation basic format for a
        ; period of time consisting of a start and end. The start MUST
        ; be before the end.

        period-start = date-time "/" dur-value
        ; [ISO.8601.1988] complete representation basic format for a
        ; period of time consisting of a start and positive duration

So if anniversary-style dates now have a default duration, but no
specific time for the start of the duration, I still see a problem
with how to represent that event's time consumption using a period of
time. I think this is also an issue for events that do specify a
DTEND, but both DTEND and DTSTART have VALUE=DATE.

Thanks for any clarification of this issue.

regards,
ben

Date: Sat, 26 May 2007 21:50:20 -0400
From: Cyrus Daboo <[email-masked]>
To: Tim Hare <[email-masked]>, [email-masked]
Subject: RE: [Ietf-calsify] RFC 2445: URL versus ATTACH property

Hi Tim,

--On May 26, 2007 8:26:31 PM -0400 Tim Hare <[email-masked]> wrote:

> I believe the best use case for URLs (not excluding what others do with
> them) is for drag-and-drop; for example I could drag the URL for the web
> site describing the Woodstock Music and Art Fair to my calendar for August
> 15th, 1969 and my calendar UI could then put the URL into some property of
> the component - it may be an X- property, or it could be COMMENT or
> DESCRIPTION.

Right its not clear exactly what the utility of using URL is as opposed to 
pasting into the DESCRIPTION field (I don't think I've seen any clients 
giving their users a way to set the COMMENT property). What's more, URL is 
only allowed once in any VEVENT, so if you wanted to put links to multiple 
items, you would have to use description anyhow.

-- 
Cyrus Daboo

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Date: Sat, 26 May 2007 20:26:31 -0400

I believe the best use case for URLs (not excluding what others do with
them) is for drag-and-drop; for example I could drag the URL for the web
site describing the Woodstock Music and Art Fair to my calendar for August
15th, 1969 and my calendar UI could then put the URL into some property of
the component - it may be an X- property, or it could be COMMENT or
DESCRIPTION.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mike Douglass
Sent: Friday, May 25, 2007 3:52 PM
To: Cyrus Daboo
Cc: [email-masked]
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property

It's one of the fields they set when they add an event.

 From the uwcal days the amount of data allowed in the description has been
limited to 500 characters. We kept it that way to prevent administrators
from putting entire documents into the description.

Our hope is to have mobile device access to the calendar and limiting the
amount of event data seems appropriate. Many of these public events already
have an associated web site or page.

We don't automate the setting (though we had thought of adding a feature to
a cms which would automatically generate an event with a link back to the
page)

Cyrus Daboo wrote:
> Hi Mike,
>
> --On May 25, 2007 10:57:03 AM -0400 Mike Douglass <[email-masked]> wrote:
>
>> In our public events calendar we present it as a link to further 
>> information - no automatic processing. Almost always points to a web 
>> page
>
> Is the value set automatically or do users/admins get to set/edit it?
>

-- 

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

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

Date: Fri, 25 May 2007 20:58:49 -0400
From: "Paul B. Hill" <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property

The lack of semantics is unfortunate. We know that for years customers 
of certain products have been asking for lazy evaluation of attendee 
lists defined by groups.

What is less frequently mentioned is that over time the location 
changes, the agenda changes, and almost any of the other descriptive 
data about an event might change. My impression is that people are 
packing the information into URLs when they can and asking user to pull 
this information because some products, and site specific product 
configurations make it difficult to capture and disseminate these 
variations otherwise.

Paul

Eliot Lear wrote:
> Cyrus,
> 
>> If, on the other hand, clients/servers attempt to do some automatic 
>> processing based on URL, then the semantics of those need to be very 
>> explicit. But the statement in the spec is very vague as to what might 
>> be there - client servers would potentially have to cope with any type 
>> of URL pointing to any type of data. The spec does not say the 
>> "dynamic rendition" has to itself be actual calendar data.
> 
> Other than passing this information to the browser it's not clear what 
> one would do, given the dearth of semantics.
> 
> Eliot
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 25 May 2007 15:51:35 -0400
From: Mike Douglass <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Cc: [email-masked]

It's one of the fields they set when they add an event.

 From the uwcal days the amount of data allowed in the description has 
been limited to 500 characters. We kept it that way to prevent 
administrators from putting entire documents into the description.

Our hope is to have mobile device access to the calendar and limiting 
the amount of event data seems appropriate. Many of these public events 
already have an associated web site or page.

We don't automate the setting (though we had thought of adding a feature 
to a cms which would automatically generate an event with a link back to 
the page)

Cyrus Daboo wrote:
> Hi Mike,
>
> --On May 25, 2007 10:57:03 AM -0400 Mike Douglass <[email-masked]> wrote:
>
>> In our public events calendar we present it as a link to further
>> information - no automatic processing. Almost always points to a web 
>> page
>
> Is the value set automatically or do users/admins get to set/edit it?
>

-- 

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

Date: Fri, 25 May 2007 11:54:03 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Douglass <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Cc: [email-masked]

Hi Mike,

--On May 25, 2007 10:57:03 AM -0400 Mike Douglass <[email-masked]> wrote:

> In our public events calendar we present it as a link to further
> information - no automatic processing. Almost always points to a web page

Is the value set automatically or do users/admins get to set/edit it?

-- 
Cyrus Daboo

Date: Fri, 25 May 2007 10:57:03 -0400
From: Mike Douglass <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property

In our public events calendar we present it as a link to further 
information - no automatic processing. Almost always points to a web page

Cyrus Daboo wrote:
> Hi Reinhold,
>
> --On May 25, 2007 8:55:16 AM +0200 Reinhold Kainhofer 
> <[email-masked]> wrote:
>
>> KOrganizer and all other KDE applications using this kind of stuff use
>> thee  ATTACH property.
>>
>>> I can only imagine that end users will actually specify an
>>> external attachment in this field, and as such, this value
>>> should be stored in the ATTACH property.
>>
>> I fully agree with your assessment here.
>>
>> The URL property (according to the wording of the RFC) should rather be
>> used  e.g. for a link to the event's page on the groupware server (e.g.
>> the page to  edit / view the event on the exchange or OpenGroupware
>> server)
>
> A more fundamental question to ask here is how clients/servers 
> actually interpret the URL property. If they simply provide a 
> clickable link for the user, then frankly, it doesn't matter what goes 
> in there, so long as it has some relevance to the event (that's how I 
> interpret the "dynamic rendition of the calendar information" 
> statement in the rfc) - and at the end of the day someone authoring an 
> event is going to put a URL that is of relevance to that event in there.
>
> If, on the other hand, clients/servers attempt to do some automatic 
> processing based on URL, then the semantics of those need to be very 
> explicit. But the statement in the spec is very vague as to what might 
> be there - client servers would potentially have to cope with any type 
> of URL pointing to any type of data. The spec does not say the 
> "dynamic rendition" has to itself be actual calendar data.
>

Date: Fri, 25 May 2007 16:53:01 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Cc: [email-masked]

Cyrus,

> If, on the other hand, clients/servers attempt to do some automatic 
> processing based on URL, then the semantics of those need to be very 
> explicit. But the statement in the spec is very vague as to what might 
> be there - client servers would potentially have to cope with any type 
> of URL pointing to any type of data. The spec does not say the 
> "dynamic rendition" has to itself be actual calendar data.

Other than passing this information to the browser it's not clear what 
one would do, given the dearth of semantics.

Eliot

Date: Fri, 25 May 2007 10:41:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property

Hi Reinhold,

--On May 25, 2007 8:55:16 AM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> KOrganizer and all other KDE applications using this kind of stuff use
> thee  ATTACH property.
>
>> I can only imagine that end users will actually specify an
>> external attachment in this field, and as such, this value
>> should be stored in the ATTACH property.
>
> I fully agree with your assessment here.
>
> The URL property (according to the wording of the RFC) should rather be
> used  e.g. for a link to the event's page on the groupware server (e.g.
> the page to  edit / view the event on the exchange or OpenGroupware
> server)

A more fundamental question to ask here is how clients/servers actually 
interpret the URL property. If they simply provide a clickable link for the 
user, then frankly, it doesn't matter what goes in there, so long as it has 
some relevance to the event (that's how I interpret the "dynamic rendition 
of the calendar information" statement in the rfc) - and at the end of the 
day someone authoring an event is going to put a URL that is of relevance 
to that event in there.

If, on the other hand, clients/servers attempt to do some automatic 
processing based on URL, then the semantics of those need to be very 
explicit. But the statement in the spec is very vague as to what might be 
there - client servers would potentially have to cope with any type of URL 
pointing to any type of data. The spec does not say the "dynamic rendition" 
has to itself be actual calendar data.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Date: Fri, 25 May 2007 08:55:16 +0200

Am Donnerstag, 24. Mai 2007 schrieb Bernard Desruisseaux:
> Both Apple iCal and Mozilla Sunbird/Lightning provides user
> interface to allow users to specify a "URL" in a calendar
> component.
>
> Both clients store the "URL" specified by the end user in the

KOrganizer and all other KDE applications using this kind of stuff use thee 
ATTACH property.

> I can only imagine that end users will actually specify an
> external attachment in this field, and as such, this value
> should be stored in the ATTACH property.

I fully agree with your assessment here.

The URL property (according to the wording of the RFC) should rather be used 
e.g. for a link to the event's page on the groupware server (e.g. the page to 
edit / view the event on the exchange or OpenGroupware server)

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: Thu, 24 May 2007 16:59:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Cc: Scott Adler <[email-masked]>, Bruno Browning <[email-masked]>

Hi Bernard,

--On May 24, 2007 3:04:59 PM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> I can only imagine that end users will actually specify an
> external attachment in this field, and as such, this value
> should be stored in the ATTACH property.
>
> What do you think?

I disagree that people would use it for attachments if the client also 
provides a separate "attach" mechanism.

-- 
Cyrus Daboo

Date: Thu, 24 May 2007 15:46:30 -0400
From: Mike Douglass <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Cc: Scott Adler <[email-masked]>, Calsify WG <[email-masked]>, Bruno Browning <[email-masked]>

We use this for public events to link to a related web site.

We discourage our administrators from trying to turn the calendar into a 
web site.

We would use attachments for providing other information - pdfs etc.

Bernard Desruisseaux wrote:
> Both Apple iCal and Mozilla Sunbird/Lightning provides user
> interface to allow users to specify a "URL" in a calendar
> component.
>
> Both clients store the "URL" specified by the end user in the
> "URL" property which is described as follows in RFC 2445:
>
> > This property may be used in a calendar component to
> > convey a location where a more dynamic rendition of
> > the calendar information associated with the calendar
> > component can be found.
>
> I'm having a really hard time believing that end users will
> actually specify "a location where a more dynamic rendition
> of the calendar information associated with the calendar
> component can be found".
>
> I can only imagine that end users will actually specify an
> external attachment in this field, and as such, this value
> should be stored in the ATTACH property.
>
> What do you think?
>
> 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) 518 276 2809(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Thu, 24 May 2007 12:23:40 -0700
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "Bernard Desruisseaux" <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property
Cc: Scott Adler <[email-masked]>, Calsify WG <[email-masked]>, Bruno Browning <[email-masked]>

On 5/24/07, Bernard Desruisseaux <[email-masked]> wrote:

> I'm having a really hard time believing that end users will
> actually specify "a location where a more dynamic rendition
> of the calendar information associated with the calendar
> component can be found".

i think this happens quite regularly in practice. for example, i often
use URL to specify evite urls for parties and upcoming.org urls for
concerts and other public events.

Date: Thu, 24 May 2007 15:04:59 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Cc: Scott Adler <[email-masked]>, Bruno Browning <[email-masked]>
Subject: [Ietf-calsify] RFC 2445: URL versus ATTACH property

Both Apple iCal and Mozilla Sunbird/Lightning provides user
interface to allow users to specify a "URL" in a calendar
component.

Both clients store the "URL" specified by the end user in the
"URL" property which is described as follows in RFC 2445:

 > This property may be used in a calendar component to
 > convey a location where a more dynamic rendition of
 > the calendar information associated with the calendar
 > component can be found.

I'm having a really hard time believing that end users will
actually specify "a location where a more dynamic rendition
of the calendar information associated with the calendar
component can be found".

I can only imagine that end users will actually specify an
external attachment in this field, and as such, this value
should be stored in the ATTACH property.

What do you think?

Cheers,
Bernard

Date: Thu, 24 May 2007 17:20:12 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] remaining issues on RFC2445bis

This is a multi-part message in MIME format.
--------------060908090102060904020208
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

We are reaching the point of diminishing returns on our work with 
RFC2445bis, and we are preparing for working group last call.  Our issue 
tracker <http://www.ofcourseimright.com/cgi-bin/roundup/calsify> shows 
the following issues as open:

Issue #
	Title
80
	Security considerations text regarding SPOOFING too restrictive
10
	Reinhold Kainhofer: end date not inclusive (VTODO only)
11
	Reinhold Kainhofer: additional examples, VTIMEZONEs, RRULEs (no text)
71
	leap seconds (we have consensus - we need a brief blurb)
70
	DST discontinuities (we have text but don't know where to put it)
81
	BYSETPOS and contracting BY* rules
82
	BYDAY integers with other BY* rules (was: BYSETPOS and contracting BY* 
rules)

The chairs would like to hear from those people who believe any of these 
issues should block WGLC.  Anyone who believes the issue should block 
should also provide a proposal as to how to close the issue.  Issues 81 
and 82 will be discussed in the next jabber meeting.  Aside from those 
two issues, and barring any objections, please expect WGLC to start 
within two weeks.

Eliot

--------------060908090102060904020208
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear all,<br>
<br>
We are reaching the point of diminishing returns on our work with
RFC2445bis, and we are preparing for working group last call.  Our <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify">issue
tracker</a> shows the following issues as open:<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="60%">
  <tbody>
    <tr>
      <td valign="top">Issue #<br>
      </td>
      <td valign="top">Title<br>
      </td>
    </tr>
    <tr>
      <td valign="top">80<br>
      </td>
      <td valign="top">Security considerations text regarding SPOOFING
too restrictive<br>
      </td>
    </tr>
    <tr>
      <td valign="top">10<br>
      </td>
      <td valign="top">Reinhold Kainhofer: end date not inclusive
(VTODO only)<br>
      </td>
    </tr>
    <tr>
      <td valign="top">11<br>
      </td>
      <td valign="top">Reinhold Kainhofer: additional examples,
VTIMEZONEs, RRULEs (no text)<br>
      </td>
    </tr>
    <tr>
      <td valign="top">71<br>
      </td>
      <td valign="top">leap seconds (we have consensus - we need a
brief blurb)<br>
      </td>
    </tr>
    <tr>
      <td valign="top">70<br>
      </td>
      <td valign="top">DST discontinuities (we have text but don't know
where to put it)<br>
      </td>
    </tr>
    <tr>
      <td valign="top">81<br>
      </td>
      <td valign="top">BYSETPOS and contracting BY* rules<br>
      </td>
    </tr>
    <tr>
      <td valign="top">82<br>
      </td>
      <td valign="top">BYDAY integers with other BY* rules (was:
BYSETPOS and contracting BY* rules)<br>
      </td>
    </tr>
  </tbody>
</table>
<br>
The chairs would like to hear from those people who believe any of
these issues should block WGLC.  Anyone who believes the issue should
block should also provide a proposal as to how to close the issue. 
Issues 81 and 82 will be discussed in the next jabber meeting.  Aside
from those two issues, and barring any objections, please expect WGLC
to start within two weeks.<br>
<br>
Eliot<br>
<br>
</body>
</html>

--------------060908090102060904020208--

Date: Thu, 24 May 2007 16:44:51 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] working issues on RFC2446bis - invitation to participate on the next revision of the iTIP standard

Dear all,

Please forward this note as appropriate.  The time has come to work to 
address all known issues with RFC2446bis.  The chairs invite all 
interested parties to indicate what issues they believe should be 
addressed.  You can open a new issue simply by sending a note to 
[email-masked] saying "NEW ISSUE" at the beginning of 
the subject line, and it will be tracked.  Now is the time to participate.

A list of open issues is available in our tracker at 
http://www.ofcourseimright.com/cgi-bin/roundup/calsify.

Thank you!

Eliot Lear
co-chair, Calsify WG

Date: Thu, 24 May 2007 10:25:51 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Proposal for issue 11

--==========1D4079119D830C8D5243==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
Re: <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11>.

The proposal to close this is to add the attached table on recurrence part 
behavior to the draft. Plus there would be some text revisions to reference 
the table at appropriate places.

Please review the attached table - Bernard will likely be adding it to the 
draft for the next revision.

-- 
Cyrus Daboo

--==========1D4079119D830C8D5243==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

RRULE Processing

A particular BYxxx rule part may expand or limit the set of date/times 
generated by the rule. The expand or limit behaviour is governed by the 
FREQ value used for the rule.

Example:

	RRULE:FREQ=MONTHLY;BYMONTH=1,3,5;BYDAY=MO,TU

		The FREQ=MONTHLY value would match each of the twelve
		months in a year.

		The BYMONTH=1,3,5 rule part limits the matching months to just
		the 1st, 3rd and 5th in a year.

		The BYDAY=MO,TU rule part adds each Monday and Tuesday within
		the matching months to the recurrence set.

The table below shows the dependency of BYxxx rule part expand or limit 
behaviour on the FREQ value in the rule. When evaluating a rule, each BYxxx 
rule part must be evaluated in the order it appears in the table (i.e. 
BYMONTH evaluated before BYWEEKNO), irrespective of the expand or limit 
behaviour.

BYDAY has some special behaviour depending on the FREQ value and this is 
described in separate notes below the table.

+--------------------------------------------------------------------------+
|          |SECONDLY|MINUTELY| HOURLY | DAILY  | WEEKLY | MONTHLY | YEARLY |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYMONTH   | Limit  | Limit  | Limit  | Limit  | Limit  | Limit   | Expand |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYWEEKNO  | Limit  | Limit  | Limit  | Limit  | Limit  | N/A     | Expand |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYYEARDAY | N/A    | N/A    | N/A    | N/A    | N/A    | N/A     | Expand |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYMONTHDAY| Limit  | Limit  | Limit  | Limit  | N/A    | Expand  | Expand |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYDAY     | Limit  | Limit  | Limit  | Limit  | Note 1 | Note 2  | Note 3 |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYHOUR    | Limit  | Limit  | Limit  | Expand | Expand | Expand  | Expand |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYMINUTE  | Limit  | Limit  | Expand | Expand | Expand | Expand  | Expand |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYSECOND  | Limit  | Expand | Expand | Expand | Expand | Expand  | Expand |
|----------+--------+--------+--------+--------+--------+---------+--------|
|BYSETPOS  | Limit  | Limit  | Limit  | Limit  | Limit  | Limit   | Limit  |
+----------+--------+--------+--------+--------+--------+---------+--------+

+--------------------------------------------------------------------+
| Note 1 | Special expand for WEEKLY.                                |
|        |                                                           |
|        | A BYDAY rule part cannot have a numeric value in a        |
|        | FREQ=WEEKLY rule (i.e. 'MO', 'TU' etc is allowed, but     |
|        | '1MO', '2TU' is not allowed).                             |
|        |                                                           |
+--------+-----------------------------------------------------------|
| Note 2 | Limit if BYYEARDAY or BYMONTHDAY is present,              |
|        | otherwise special expand for MONTHLY.                     |
|        |                                                           |
|        | The numeric value in a BYDAY rule part in a FREQ=MONTHLY  |
|        | rule corresponds to an offset with the month.             |
|        |                                                           |
+--------+-----------------------------------------------------------|
| Note 3 | Limit if BYYEARDAY or BYMONTHDAY is present,              |
|        | otherwise special expand for WEEKLY if BYWEEKNO present,  |
|        | otherwise special expand for MONTHLY if BYMONTH present,  |
|        | otherwise special expand for YEARLY.                      |
|        |                                                           |
|        | A BYDAY rule part cannot have a numeric value in a        |
|        | FREQ=YEARLY rule (i.e. 'MO', 'TU' etc is allowed, but     |
|        | '1MO', '2TU' is not allowed), if BYWEEKNO is specified.   |
|        |                                                           |
|        | The numeric value in a BYDAY rule part in a FREQ=YEARLY   |
|        | rule with a BYMONTH present corresponds to an offset with |
|        | the month.                                                |
|        |                                                           |
|        | The numeric value in a BYDAY rule part in a FREQ=YEARLY   |
|        | rule without BYWEEKNO or BYMONTH present corresponds to   |
|        | an offset within the year.                                |
|        |                                                           |
+--------+-----------------------------------------------------------+

--==========1D4079119D830C8D5243==========--

From: Aki Niemi <[email-masked]>
To: CALSIFY list <[email-masked]>
Organization: Nokia
Date: Thu, 24 May 2007 15:21:33 +0300
Subject: [Ietf-calsify] Jabber chat today

Folks,

It's been awfully quiet here this past week, and I just realized that
the invitation for the Jabber chats sent to the list originally also was
*not* recurring, although we are having weekly chats. Sorry for the
confusion.

Nevertheless, we're on for today, at 10:00 EDT / 16:00 CEST / 17:00
EEST. The room is at [email-masked]. Please join.

We are going to check where we are with RFC2445bis issues, and move on
to RFC2446bis issue discussion.

Welcome!

Cheers,
Aki

Date: Thu, 17 May 2007 16:51:02 +0300 (EEST)
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Reminder: Jabber chat today

Jabber chat at [email-masked] starting in about ten minutes.

Cheers,
Aki

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Thu, 3 May 2007 17:09:29 +0200
Subject: [Ietf-calsify] iCal event invitation: Calsify Jabber Sessions

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

Eliot Lear has invited you to the iCal event: Calsify Jabber  
Sessions, scheduled for May 17, 2007 at 4:00 PM (Europe/Zurich). To  
accept or decline this invitation, click the link below.

--Apple-Mail-1-181791181
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20070503-170921.ics
Content-Disposition: attachment;
	filename=iCal-20070503-170921.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:Europe/Zurich=0D=0A=
LAST-MODIFIED:20070503T150921Z=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070325T010000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20071028T030000=0D=0ATZOFFSETTO:+0100=0D=0ATZOFFSETFROM:+0200=0D=0A=
TZNAME:CET=0D=0AEND:STANDARD=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
ATTENDEE;CN=3D"CALSIFY=20=
Mailinglist":mailto:[email-masked]=0D=0A=
ATTENDEE;CN=3D"Cyrus=20Daboo":mailto:[email-masked]=0D=0A=
ATTENDEE;CN=3D"Bernard=20=
Desruisseaux":mailto:[email-masked]=0D=0A=20m=0D=0A=
ATTENDEE;CN=3D"Aki=20Niemi":mailto:[email-masked]=0D=0A=
ATTENDEE;CN=3D"Alexey=20Melnikov":mailto:[email-masked]=0D=0A=
LOCATION:[email-masked]=0D=0ADTSTAMP:20070503T150921Z=0D=0A=
UID:B33CCCA6-1B37-407B-AFC8-D5A52FB42B88=0D=0ASEQUENCE:12=0D=0A=
DTSTART;TZID=3DEurope/Zurich:20070517T160000=0D=0ASUMMARY:Calsify=20=
Jabber=20Sessions=0D=0ADTEND;TZID=3DEurope/Zurich:20070517T170000=0D=0A=
DESCRIPTION:Agenda:\n\nReview=20open=20issues=20for=202445bis=20and=20=
2446bis.\n\nWe=0D=0A=20're=20almost=20there\,=20everyone!=20=20Please=20=
participate!\n\nEliot=0D=0AORGANIZER;CN=3D"Eliot=20=
Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A=

--Apple-Mail-1-181791181--

Date: Thu, 03 May 2007 15:58:52 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] conference call Thusday this week at 10:00am EDT
Cc: Cyrus Daboo <[email-masked]>

One amendment to the instructions: Use Meeting Id 312147852.

Regards,

Eliot

Eliot Lear wrote:
> Dear all,
>
> We would like to hold a brief conference call on Thursday, May 3rd, at 
> 10:00am EDT.  Please see the instructions below to access the 
> meeting.  If you plan to attend, please send me an email so I can 
> ensure we have enough ports.  Any technical discussions that are 
> discussed will be raised on the mailing list.  The primary purpose of 
> the meeting, however, is to establish times for Jabber sessions, and 
> to understand scope of remaining work.
>
> Thanks,
>
> Eliot
>
> *Global Access Numbers:*
> *http://cisco.com/en/US/about/doing_business/conferencing/index.html*
>
>    * US/Canada:*  +1.866.432.9903   * United Kingdom:*   +44.20.8824.0117
>    * India:*      +91.80.4103.3979  * Germany:*          
> +49.619.6773.9002
>    * Japan:*      +81.3.5763.9394   * China:*            +86.10.8515.5666
>
> *TO ATTEND A WEB AND VOICE CONFERENCE*
>
> *CISCO INTRANET ATTENDEES*
> *Join the Web & Voice Conference**
> 1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
> 2. Enter your* CEC User ID* &* Password* then click* OK*
> - Accept any security warnings you receive and wait for the Meeting 
> Room to initialize
> 3. Click on* CONNECT* from the Meeting Room to join the Voice 
> Conference portion of the meeting
>
> *EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
> *Join the Web & Voice Conference**
> 1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
> 2. Fill in the* My Name is* field then click* Attend Meeting*
> - If you have a* CEC User ID*, click on the* Cisco icon*
> - Accept any security warnings you receive and wait for the Meeting 
> Room to initialize
> 3. Click on* CONNECT* from the Meeting Room to join the Voice 
> Conference portion of the meeting
>
> ***If this is your first time attending a Web Conference, disable any 
> pop-up blockers and visit* 
> http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to 
> test your web browser for compatibility with the Web Conference.
>
> ****Not all meetings are scheduled to allow external attendees into 
> the Web Conference portion of the meeting, if the URL does not work, 
> please follow the Voice only Conference instructions below to attend.
>
> *TO ATTEND A VOICE ONLY CONFERENCE*
> 1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or 
> link above)
> 2. Press* 1* to attend the meeting
> 3. Follow the prompts to enter the Meeting ID* 312147852* and join the 
> meeting
>
> *SUPPORT*
> *Information about this Conference:* Contact Eliot Lear, 41448787525
> *Cisco IT Support Center:* Attend the Voice Conference and then press 
> #0 on your phone keypad
>
> *GLOBAL ACCESS NUMBERS*
>
> *COUNTRY            LOCATION           LOCAL NUMBER            TOLL 
> FREE-FREEFONE*
> *AMERICAS*          
> *United States*      East               +1.919.392.3330         
> 1.866.349.3520
>                    West               +1.408.525.6800         
> 1.866.432.9903
> *Argentina*          Buenos Aires       +54.11.4341.0101
> *Brazil*             Brasilia           +55.613.424.0220
>                    Rio de Janeiro     +55.21.2483.6302
>                    Sao Paulo          +55.11.5508.6311
> *Canada*             Calgary            +1.403.514.2435
>                    Edmonton           +1.780.441.3715
>                    Halifax            +1.902.474.0214
>                    Kanata             +1.613.254.0005
>                    Markham            +1.905.470.4810
>                    Montreal           +1.514.847.6875
>                    Ottawa             +1.613.788.7250
>                    Quebec             +1.418.634.5645
>                    Regina             +1.306.566.6410
>                    Toronto            +1.416.306.7230
>                    Vancouver          +1.604.647.2350
>                    Winnipeg           +1.204.336.6610
> *Chile*              Santiago           +56.2.431.4936
> *Costa Rica*         San Jose           +506.201.3617
> *Colombia*           Bogota             +57.1.325.6065
> *Dominican Republic* Santo Domingo      +1.809.683.1222
> *Mexico*             Guadalajara        +52.33.3770.1206
>                    Mexico City        +52.55.5267.1800
>                    Monterrey          +52.818.221.2462   
> *Peru*               Lima               +51.1.215.5101
> *Puerto Rico*        San Juan           +1.787.620.1865
> *Venezuela*          Caracas            +58.212.902.0210
> *EUROPE*              
> *Austria*            Vienna             +43.12.4030.6022
> *Belgium*            Diegem             +32.2.704.5072
> *Bulgaria*           Sofia              +359.2.937.5938
> *Croatia*            Zagreb             +385.1.462.8908
> *Czech Republic*     Prague             +420.22.143.5100
> *Denmark*            Aabyhoj            +45.8.939.7131
>                    Copenhagen         +45.3.958.5010
> *Estonia*            Tallinn            +358.204.70.6227
> *Finland*            Espoo              +358.204.70.6227
> *France*             Paris              +33.15.804.3116
> *Germany*            Eschborn           +49.619.6773.9002
>                    Hallbergmoos       +49.811.554.3016
> *Greece*             Athens             +30.210.638.1303
> *Hungary*            Budapest           +36.1.225.4621
> *Ireland*            Dublin             +353.1.819.2717
> *Israel*             Netanya            +972.9.892.7026
> *Italy*              Rome               +39.06.5164.4006
> *Latvia*             Riga               +358.204.70.6227
> *Netherlands*        Amsterdam          +31.20.357.1487
> *Norway*             Oslo               +47.23.27.3647
> *Poland*             Warsaw             +48.22.572.2615
> *Portugal*           Lisbon             +351.21.446.8756
> *Slovakia*           Bratislava         +421.2.5825.5309
> *South Africa*       Cape Town          +27.21.413.4502
>                    Johannesburg       +27.11.267.1011
>                    Pretoria           +27.12.844.7401
> *Spain*              Barcelona          +34.93.393.4037
>                    Madrid             +34.91.201.2149
> *Sweden*             Gothenburg         +46.31.63.4409
>                    Stockholm          +46.8.685.9035
> *Switzerland*        Glattzentrum       +41.44.878.7335
> *Turkey*             Istanbul           +90.212.335.0208
> *United Arab*
> *Emirates* (UAE)     Dubai              +971.4.390.7840
> *United Kingdom*     Bedfont Lakes      +44.20.8824.0117
>                    Edinburgh          +44.131.561.3643
>                    London City        +44.20.7496.3743
> *ASIA PACIFIC*
> *Australia*          Canberra           +61.2.6216.0643          
> 86.16.0643
>                    Melbourne          +61.3.9659.4173
>                    North Sydney       +61.2.8446.5260
> *China*              Beijing            +86.10.8515.5666
>                    Shanghai           +86.21.2302.4200
> *Hong Kong*          Hong Kong          +852.3414.1802
> *India*              Bangalore          +91.80.4103.3979
>                    Hyderabad          +91.40.4022.3450
>                    Mumbai IL & FS     +91.22.4043.4030
>                    New Delhi          +91.11.4261.1088
> *Indonesia*          Jakarta            +62.21.7854.7476
> *Japan*              Tokyo Akasaka      +81.3.5763.9394
> *South Korea*        Seoul Asem         +82.2.3429.8102
> *Malaysia*           Kuala Lumpur       +60.3.7723.8620
>                    Penang             +60.4.631.5125
> *New Zealand*        Auckland           +64.9.355.1968
>                    Wellington         +64.4.496.5554
> *Philippines*        Makati (Manila)    +63.2.750.5886
> *Singapore*          Singapore Capital  +65.6317.7088
> *Taiwan*             Taipei             +886.2.8758.7088
> *Thailand*           Bangkok            +66.2.263.7008
> *Vietnam*            Hanoi              +84.4.974.6250
>                    Ho Chi Minh City   +84.8.823.3418
>                    (Saigon)                  
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>