Subject: [Ietf-calsify] floating RRULEs and UNTIL values

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Wed Jun 27 14:41:09 2007

There are a few places in draft 6 that say something like this:

      The UNTIL rule part defines a DATE or DATE-TIME value which bounds
      the recurrence rule in an inclusive manner.  If the value
      specified by UNTIL is synchronized with the specified recurrence,
      this DATE or DATE-TIME becomes the last instance of the
      recurrence.  The value of the UNTIL rule part MUST have the same
      value type as the "DTSTART" property.  If specified as a DATE-TIME
      value, then it MUST be specified in a UTC time format.  If not
      present, and the COUNT rule part is also not present, the "RRULE"
      is considered to repeat forever.

and later,

      *  If observance is known to have an effective end date, the
         "UNTIL" recurrence rule parameter MUST be used to specify the
         last valid onset of this observance (i.e., the UNTIL date-time
         will be equal to the last instance generated by the recurrence
         pattern).  It MUST be specified in UTC time.

What about recurring floating events?  Seems like we're either
forbidding floating events from using UNTIL, or we're saying even
floating recurring events need to have UNTIL values in UTC, which I
think is a bad idea.

How about removing the latter paragraph's insistence on UTC, since it
doesn't apply to DATE valued recurring events or floating events, and
changing the first to:

      The UNTIL rule part defines a DATE or DATE-TIME value which bounds
      the recurrence rule in an inclusive manner.  If the value
      specified by UNTIL is synchronized with the specified recurrence,
      this DATE or DATE-TIME becomes the last instance of the
      recurrence.  The value of the UNTIL rule part MUST have the same
      value type as the "DTSTART" property.  If DTSTART is specified as
      a DATE-TIME value with a timezone, then UNTIL MUST be specified in
      a UTC time format.  If DTSTART is specified as a floating
      DATE-TIME, UNTIL MUST specified as a floating DATE-TIME.  If not
      present, and the COUNT rule part is also not present, the "RRULE"
      is considered to repeat forever.

Sincerely,
Jeffrey

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jun 27 19:39:15 2007

Here's how the story goes:

- The requirement to have UNTIL specified in UTC was specified
   in RFC 2445:

   > If specified as a date-time value, then it MUST be specified
   > in an UTC time format.

- At the 66th IETF Meeting in Montreal (July 2006) we've agreed
   to clarify that the value of the UNTIL rule part MUST have the
   same value type as the "DTSTART" property (Issue 23). As you'll
   see in the minutes the issue you are bringing up was briefly
   discussed:

   http://www3.ietf.org/proceedings/06jul/minutes/calsify.txt

   > 4 4.3.10 on UNTIL rule.  Should clarify whether UNTIL can use a DATE
   > value type.
   >
   > AI: Room showing agreement that the draft should state that
   > the UNTIL value type MUST match DTSTART value type.
   >
   > Another issue with whether UNTIL DATE-TIME should be allowed to float
   > or not (currently UTC a MUST). Might still be a problem if DTSTART is
   > a local time; however, JeffMc points out later that DTSTART is not
   > allowed to float currently, so should not be an issue.

- At the 67th IETF meeting in San Diego (November 2006) we've agreed
   to clarify that all forms of DATE-TIME were allowed for DTSTART and
   DTEND/DUE in recurring components (i.e., also DATE WITH UTC TIME).
   (Issue 43). Except for VTIMEZONE sub-components where DTSTART is
   REQUIRED to be in UTC:

   http://tools.ietf.org/wg/calsify/minutes?item=minutes67.html

   You can also check:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-September/001172.html

- Also in November 2006, Tim and Cyrus pointed out that we must allow
   floating time recurring events.  See thread:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001353.html

Given what was previously agreed for issue 23 and issue 43 I believe
a change to the specification for the UNTIL rule part is advisable.

In the case of VTIMEZONE sub-components the DTSTART is specified as a
date with local time but is not really floating since "TZOFFSETFROM"
always gives you its UTC offset. As such it does make sense to have
a "floating" DTSTART and an UNTIL rule part with a UTC time in a
VTIMEZONE sub-component.

In the case of VEVENT components if the DTSTART is specified as a
date with local time and the UNTIL rule part is specified as a date
with UTC time then people in different time zones could end up with
a different number of recurrence instances.  Not good.

Given all of the above, here's what I propose:

  The UNTIL rule part MUST be specified as a date with UTC time,
  unless DTSTART is specified as a date with local time, except
  in VTIMEZONE sub-components where the UNTIL rule part MUST
  always be specified as a date with UTC time.

Thanks,
Bernard

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

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Thu Jun 28 17:21:03 2007

Hi Bernard,

>  always be specified as a date with UTC time.

Yup, that sounds fine.

Sincerely,
Jeffrey

Date: Thu, 28 Jun 2007 17:19:56 -0700
From: Jeffrey Harris <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] floating RRULEs and UNTIL values

Hi Bernard,

>  always be specified as a date with UTC time.

Yup, that sounds fine.

Sincerely,
Jeffrey

Date: Thu, 28 Jun 2007 15:57:26 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts now

topic will be itip

X-Http_host: webmail.rpi.edu
Date: Thu, 28 Jun 2007 1:39:08 -0400
MIME-Version: 1.0
Organization: Rensselaer Polytechnic Institute
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameter  specified on DATE property
X-Mailer: EMUmail 6.0.1.30
From: [email-masked]
X-Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20061201 Firefox/2.0.0.4 (Ubuntu-feisty)
X-Webmail-User: [email-masked]
To: [email-masked]
X-RPI-SA-Score: undef - spam scanning disabled
X-CanItPRO-Stream: default
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226
Cc: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [email-masked]
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 05:40:12 -0000

I suppose I agree with reservations...

>From a ui perspective it's useful to be able to flag something as an all
day event without the precision implied by setting the start and end to
specific times.

For personal events it's probably not an issue. However, when trying to
use rfc2445 objects to advertise public events it's more problematical.

For example, we have graduation at RPI. It doesn't start at midnight and
end at midnight but for all intents and purposes it's an all-day event.
Some of it is webcast. If we mark it as an all day event without a
timezome the New Zealand parents will tune in 12 hours out (assuming they 
trust calendars and timezones).

One solution is to allow a TZID on a DATE. Then we interpret the date in
the intended timezone - whatever our personal timezone. This appears to
be a matter of just firming up an omission in the rfc.

Also it doesn't disallow 'floating' dates i.e  a DATE without a TZID so
we can still say - all day on March 15th is my birthday (yes it is)

Another option is to flag date/time as being really all day - microsoft
have an x-property which does just that. This would work but seems more
complex.

All-day already has some implied fuzziness to it which is useful and
perhaps we should extend that rather than trying to add fuzziness to a
precise definition of time implied by DATETIME

==============Original message text===============
On Wed, 27 Jun 2007 13:15:51 EDT Bernard Desruisseaux wrote:

Section 4.2.19 Time Zone Identifier of RFC 2445 says nothing about the
use of the TZID parameter on DATE properties. This section specifies
when this parameter MUST or MUST NOT be specified on DATE-TIME or TIME
values, but says nothing about DATE.

Furthermore, unlike section 4.3.5 Date-Time, section 4.3.4 Date doesn't
discuss the TZID parameter at all.

I'm bringing this up since Mozilla Sunbird specifies the TZID parameter
on DTSTART and DTEND of "All Day" events. For instance, here's an All
Day VEVENT created by Mozilla Sunbird with my time zone set to
Asia/Shanghai (UTC+08:00):

BEGIN:VEVENT
CREATED:20070627T160534Z
LAST-MODIFIED:20070627T160607Z
DTSTAMP:20070627T160650Z
UID:d9a9e2e4-4123-4b06-8dca-c10f791f8700
SUMMARY:All Day Event June 28th 2007 (Asia/Shanghai UTC+08:00)
DTSTART;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070628
DTEND;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070629
END:VEVENT

To find out whether Mozilla Sunbird actually cares about the TZID
itself I changed my time zone to America/Montreal (UTC-4:00). Given
that June 28th, 2007 00:00 (midnight) Asia/Shanghai corresponds to
June 27th, 12:00 (noon) America/Montreal I was wondering if this
All Day event would be displayed on June 27th, 2007. It turns out
that Mozilla Sunbird still displayed the event on June 28th.

    Note: If you want to try this yourself with Mozilla Sunbird,
    you'll actually need to change the time zone of your OS to
    match the time zone you configured in Mozilla Sunbird.  Else
    Mozilla Sunbird will end up creating the All Day event on the
    wrong day altogether. For instance, if you configure Sunbird
    with Asia/Shanghai but have your OS configured with
    America/Montreal and create an All Day event on June 28th, 2007,
    Mozilla Sunbird will create an All Day event that start on
    June 29th!

While iCalendar currently doesn't forbid the use of the TZID parameter
on DATE value properties, it certainly doesn't look like it was ever
meant to be used. If one wants to ground a given DATE to midnight of
a specific time zone I believe one should simply use a DATE-TIME value.

I propose to change the following statement in section 4.2.19 Time Zone
Identifier, from:

 > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
 > properties whose time values are specified in UTC.

to:

 > The TZID property parameter MUST NOT be applied to DATE properties,
 > and DATE-TIME or TIME properties whose time values are specified in
 > UTC.

Cheers,
Bernard
===========End of original message text===========

-- 

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: Wed, 27 Jun 2007 22:43:58 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time

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

Would we be okay to had the following MUST requirements:

If DTSTART is specified as a "DATE WITH UTC TIME" (FORM #2) or
a "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE" (FORM #3) then
DTEND/DUE *MUST* be specified as either a "DATE WITH UTC TIME"
(FORM #2) or a "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE"
(FORM #3).  Else, if DTSTART is specified as a "DATE WITH LOCAL
TIME" (FORM #1) then DTEND/DUE *MUST* also be specified as a
"DATE WITH LOCAL TIME" (FORM #1).

Cheers,
Bernard

Bernard Desruisseaux wrote:
> [ Note to the chairs: This issue is related to issue 65. ]
> 
> This is currently specified as a SHOULD in section 6 Recommended
> Practices of RFC 2445:
> 
>  > 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).
> 
> I wouldn't mind adding a requirement to specify that if DTSTART is
> specified as a "DATE WITH LOCAL TIME" (FORM #1) then DTEND/DUE MUST
> also be specified as a "DATE WITH LOCAL TIME" (FORM #1).
> 
> That being said, I think we could accept DTSTART and DTEND/DUE to mix
> "DATE WITH UTC TIME" (FORM #2) with "DATE WITH LOCAL TIME AND TIME
> ZONE REFERENCE" (FORM #3).
> 
> Finally, as was already clarified for issue 65, if DTSTART and DTEND/DUE
> are both specified as "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE"
> (FORM #3) a different time zone MAY be used for each property.
> 
> Cheers,
> Bernard
> 
> Arnaud Quillaud wrote:
>> The Calsify draft now clarifies in the DTEND definition that:
>> <<
>> The value type
>>    of this property MUST be the same as the "DTSTART" property, and
>>    the value of this property MUST be later in time than the value of
>>    the "DTSTART" property.
>> (See 
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001519.html). 
>>
>>
>> Nevertheless the value type just allows us to distinguish between DATE 
>> and DATETIME.
>>
>> Shouldn't we go one step further and say that if the DTSTART value 
>> type is FORM #1: DATE WITH LOCAL TIME (See 
>> http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), 
>> DTEND should also be of the same form.
>> Otherwise, if we allow a mix of floating time + utc time (or time with 
>> tz), one can create an event which is valid in some timezones but 
>> invalid in some others (you may end up with DTEND < DTSTART).
>>
>>
>> Arnaud Q
>>

Date: Wed, 27 Jun 2007 22:37:42 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Jeffrey Harris <[email-masked]>
Subject: Re: [Ietf-calsify] floating RRULEs and UNTIL values
Cc: Calsify WG <[email-masked]>

   You can also check:

Thanks,
Bernard

>       is considered to repeat forever.

Date: Wed, 27 Jun 2007 14:40:05 -0700
From: Jeffrey Harris <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] floating RRULEs and UNTIL values

and later,

Sincerely,
Jeffrey

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameterspecified on DATE property
Date: Wed, 27 Jun 2007 23:03:46 +0200

Am Mittwoch, 27. Juni 2007 schrieb Nigel Swinson:
> > > I propose to change the following statement in section 4.2.19 Time Zone
> > >
> > > Identifier, from:
> > > > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
> > > > properties whose time values are specified in UTC.
> > >
> > > to:
> > > > The TZID property parameter MUST NOT be applied to DATE properties,
> > > > and DATE-TIME or TIME properties whose time values are specified in
> > > > UTC.
> >
> > Hooray!  I second the change.
>
> We'd encountered this issue and come to similar conclusions, so I'd also be
> happy for the clarity offered by this change.

Just another "Me too" from my side.
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/

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 455b75f593e13070f4ebd399412bcfaf
X-Spam-Score-Summary: 2, 0, 0, cdd93278e63df3ee, 79df6408548511e2, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1538:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2828:3027:3352:3865:3867:3868:3870:4250:5007, 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: "Bernard Desruisseaux" <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameterspecified on DATE property
Date: Wed, 27 Jun 2007 21:29:06 +0100
Cc: Calsify WG <[email-masked]>

> > I propose to change the following statement in section 4.2.19 Time =
Zone
> > Identifier, from:
> >
> > > The TZID property parameter MUST NOT be applied to DATE-TIME or =
TIME
> > > properties whose time values are specified in UTC.
> >
> > to:
> >
> > > The TZID property parameter MUST NOT be applied to DATE =
properties,
> > > and DATE-TIME or TIME properties whose time values are specified =
in
> > > UTC.
> >
> Hooray!  I second the change.

We'd encountered this issue and come to similar conclusions, so I'd also =
be happy for the clarity offered by this change.

Nigel

Date: Wed, 27 Jun 2007 12:45:12 -0500
From: Clint Talbert <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameter specified on DATE property
Cc: Calsify WG <[email-masked]>

Bernard Desruisseaux wrote:
> Section 4.2.19 Time Zone Identifier of RFC 2445 says nothing about the
> use of the TZID parameter on DATE properties. This section specifies
> when this parameter MUST or MUST NOT be specified on DATE-TIME or TIME
> values, but says nothing about DATE.
>
> Furthermore, unlike section 4.3.5 Date-Time, section 4.3.4 Date doesn't
> discuss the TZID parameter at all.
>
I'm glad that you're addressing this because I believe the behavior you 
note resulted from a misunderstanding of section 4.3.4.
> .. snip..

> To find out whether Mozilla Sunbird actually cares about the TZID
> itself I changed my time zone to America/Montreal (UTC-4:00). Given
> that June 28th, 2007 00:00 (midnight) Asia/Shanghai corresponds to
> June 27th, 12:00 (noon) America/Montreal I was wondering if this
> All Day event would be displayed on June 27th, 2007. It turns out
> that Mozilla Sunbird still displayed the event on June 28th.
>
I believe this is the proper behavior, to tie the all-day event to a 
specific numerical date.  It sounds like you also think so, given the 
change you suggest below.
>    Note: If you want to try this yourself with Mozilla Sunbird,
>    you'll actually need to change the time zone of your OS to
>    match the time zone you configured in Mozilla Sunbird.  Else
>    Mozilla Sunbird will end up creating the All Day event on the
>    wrong day altogether. For instance, if you configure Sunbird
>    with Asia/Shanghai but have your OS configured with
>    America/Montreal and create an All Day event on June 28th, 2007,
>    Mozilla Sunbird will create an All Day event that start on
>    June 29th!
>
This is an unfortunate, known issue in Sunbird/Lightning that we are 
addressing in our next (0.7) release (work is actually underway on it, 
though the bug report below does not reflect it). I apologize for the 
inconvenience. 

For more information, please see: 
https://bugzilla.mozilla.org/show_bug.cgi?id=337191.  And if you'd like 
to be notified of changes to the bug, feel free to CC yourself on it.
>
> I propose to change the following statement in section 4.2.19 Time Zone
> Identifier, from:
>
> > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
> > properties whose time values are specified in UTC.
>
> to:
>
> > The TZID property parameter MUST NOT be applied to DATE properties,
> > and DATE-TIME or TIME properties whose time values are specified in
> > UTC.
>
Hooray!  I second the change.

I'll file another bug to no longer add TZID to DATE properties in 
Sunbird as well.  Thanks for bringing this to our attention. :-)

Thanks,

Clint Talbert
Mozilla Calendar Project QA Coordinator

Date: Wed, 27 Jun 2007 13:15:51 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameter specified on DATE property

Section 4.2.19 Time Zone Identifier of RFC 2445 says nothing about the
use of the TZID parameter on DATE properties. This section specifies
when this parameter MUST or MUST NOT be specified on DATE-TIME or TIME
values, but says nothing about DATE.

Furthermore, unlike section 4.3.5 Date-Time, section 4.3.4 Date doesn't
discuss the TZID parameter at all.

I'm bringing this up since Mozilla Sunbird specifies the TZID parameter
on DTSTART and DTEND of "All Day" events. For instance, here's an All
Day VEVENT created by Mozilla Sunbird with my time zone set to
Asia/Shanghai (UTC+08:00):

BEGIN:VEVENT
CREATED:20070627T160534Z
LAST-MODIFIED:20070627T160607Z
DTSTAMP:20070627T160650Z
UID:d9a9e2e4-4123-4b06-8dca-c10f791f8700
SUMMARY:All Day Event June 28th 2007 (Asia/Shanghai UTC+08:00)
DTSTART;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070628
DTEND;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070629
END:VEVENT

To find out whether Mozilla Sunbird actually cares about the TZID
itself I changed my time zone to America/Montreal (UTC-4:00). Given
that June 28th, 2007 00:00 (midnight) Asia/Shanghai corresponds to
June 27th, 12:00 (noon) America/Montreal I was wondering if this
All Day event would be displayed on June 27th, 2007. It turns out
that Mozilla Sunbird still displayed the event on June 28th.

    Note: If you want to try this yourself with Mozilla Sunbird,
    you'll actually need to change the time zone of your OS to
    match the time zone you configured in Mozilla Sunbird.  Else
    Mozilla Sunbird will end up creating the All Day event on the
    wrong day altogether. For instance, if you configure Sunbird
    with Asia/Shanghai but have your OS configured with
    America/Montreal and create an All Day event on June 28th, 2007,
    Mozilla Sunbird will create an All Day event that start on
    June 29th!

While iCalendar currently doesn't forbid the use of the TZID parameter
on DATE value properties, it certainly doesn't look like it was ever
meant to be used. If one wants to ground a given DATE to midnight of
a specific time zone I believe one should simply use a DATE-TIME value.

I propose to change the following statement in section 4.2.19 Time Zone
Identifier, from:

 > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
 > properties whose time values are specified in UTC.

to:

 > The TZID property parameter MUST NOT be applied to DATE properties,
 > and DATE-TIME or TIME properties whose time values are specified in
 > UTC.

Cheers,
Bernard

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Struggling with BYxxx
Date: Sun, 24 Jun 2007 00:26:20 +0200

Am Samstag, 23. Juni 2007 schrieb Mr. Demeanour:
> Hi,
>
> What is the correct interpretation of a YEARLY rule in which BYMONTH and
> BYYEARDAY are both specified?
>
> I can't find this described anywhere, but my interpretation would be to
> /expand/ in accordance with the BYMONTH part, and then to /expand/ in
> accordance with the BYYEARDAY part. So consider the rule
>
>      RRULE:FREQ=YEARLY;BYMONTH=6,12;BYMONTHDAY=25;BYYEARDAY=1
>
> I would expect this rule to expand to two Christmases per year, on the
> 25th of June and December respectively, and one New Year's Day.
>
> Is that correct?

I don't think so. The dates matched by the rule have to fulfill all the BY* 
restrictions. In your case, there are not dates that are the first day of the 
year and lie in June or december...

Or to make it more formal according to the evaluation order in the RFC:
For year YY, the recurrence set is generated as:
BYMONTH: Only all days in June or December
BYYEARDAY: only those days in the set that are the first day of the year 
(which are none, so our recurrence set is empty here, already).
BYMONTHDAY: No effect, since the set is already empty.

The BY* rule parts must all be matched by a date/time in the recurrence set, 
but the BY* rule part values (e.g. 6,12 for BYMONTH here) are or'ed together.

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: Sat, 23 Jun 2007 12:40:23 +0100
From: "Mr. Demeanour" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Struggling with BYxxx

Hi,

What is the correct interpretation of a YEARLY rule in which BYMONTH and
BYYEARDAY are both specified?

I can't find this described anywhere, but my interpretation would be to
/expand/ in accordance with the BYMONTH part, and then to /expand/ in
accordance with the BYYEARDAY part. So consider the rule

     RRULE:FREQ=YEARLY;BYMONTH=6,12;BYMONTHDAY=25;BYYEARDAY=1

I would expect this rule to expand to two Christmases per year, on the
25th of June and December respectively, and one New Year's Day.

Is that correct?

Thanks,
Jack.

Date: Thu, 21 Jun 2007 13:41:13 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] OT: Anyone know anyone at Apple 

I'm hitting a problem with RFC-2445 compatibility on Apple iCal (2.0.5).

Essentially, the presence of an RDATE entry in an iCal file will cause 
iCal to terminate with some sort of exception. I suppose that if someone 
were really interested, this could probably be exploited to do something 
bad.

I've submitted it as a bug at least 3 times to Apple over the past year, 
and it's just not getting fixed.

If anyone could mail me off list with information to contact someone at 
Apple I would appreciate it.

-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/

Date: Thu, 21 Jun 2007 17:15:15 +0100
From: Alexey Melnikov <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
Cc: "[email-masked]" <[email-masked]>

Eliot Lear wrote:

> Alexey Melnikov wrote:
>
>>
>> I think all templates need to have a Usage field, which contains one 
>> of the following: limited, global, obsolete.
>
> Sounds like you're mixing semantics.  Do you mean "status"?  I think 
> that's important too.

SASL registry uses "Usage", which is one of "limited", "common" or 
"obsolete". "obsolete" is something that shouldn't be used. "common" is 
something that is applicable to various use cases. "limited" is 
something known to be somewhat restricted/broken, but not sufficiently 
bad in order to be marked "obsolete".

So what do you mean by "status"?

>   Also...
>
>>> X.X.X  Registration Template for New Components
>>>
>>>     A component is defined by completing the following template.
>>>
>>>         To: [email-masked]
>>>
>>>         Subject: Registration of new iCalendar component XXX
>>>
>>>         Component Name:
>>>
>>>         Purpose:
>>>
>>>         Format Definition:
>>>
>>>         Description:
>>
> You don't need the "To: " line.

This is more of a convention used by many IANA templates.

Date: Thu, 21 Jun 2007 16:02:38 +0200
From: Eliot Lear <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
Cc: "[email-masked]" <[email-masked]>

Alexey Melnikov wrote:
>
> I think all templates need to have a Usage field, which contains one 
> of the following: limited, global, obsolete.

Sounds like you're mixing semantics.  Do you mean "status"?  I think 
that's important too.  Also...
>
>> X.X.X  Registration Template for New Components
>>
>>     A component is defined by completing the following template.
>>
>>         To: [email-masked]
>>
>>         Subject: Registration of new iCalendar component XXX
>>
>>         Component Name:
>>
>>         Purpose:
>>
>>         Format Definition:
>>
>>         Description:
>

You don't need the "To: " line.

Eliot

Date: Thu, 21 Jun 2007 14:53:38 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
Cc: "[email-masked]" <[email-masked]>

Hi Bernard,
Some questions/comments about the proposed templates below:

Bernard Desruisseaux wrote:

>>> Also, I think we should consider having 4 templates:
>>>
>>> - Registration of New Components
>>> - Registration of New Properties
>>> - Registration of New Parameters
>>> - Registration of New Values
>>>
>>> What do you think?
>>
>>
>> I think there needs to be a substantial difference in the templates 
>> to justify four of them.  Do you think there is?
>
>
> Here's what I have in mind.  A total of 5 templates.
>
>   - Registration Template for New Components
>   - Registration Template for New Properties
>   - Registration Template for New Parameters
>   - Registration Template for New Value Data Types
>   - Registration Template for New Values

I think all templates need to have a Usage field, which contains one of 
the following: limited, global, obsolete.

> X.X.X  Registration Template for New Components
>
>     A component is defined by completing the following template.
>
>         To: [email-masked]
>
>         Subject: Registration of new iCalendar component XXX
>
>         Component Name:
>
>         Purpose:
>
>         Format Definition:
>
>         Description:

How is Purpose different from Description?

What is Format Definition? Is it supposed to be ABNF or RFC reference?

>         Example:
>
> X.X.X  Registration Template for New Properties
>
>     A property is defined by completing the following template.
>
>         To: [email-masked]
>
>         Subject: Registration of new iCalendar property XXX
>
>         Property name:
>
>         Purpose:
>
>         Value type(s):
>
>         Property parameter(s):
>
>         Conformance:

And this is an RFC reference? Why have you omitted this from the 
previous template?

>         Description:
>         Format definition:
>         Example(s):

Date: Thu, 21 Jun 2007 15:36:40 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts in 20 minutes

see you there!

Date: Wed, 20 Jun 2007 15:00:58 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
Cc: Eliot Lear <[email-masked]>, "[email-masked]" <[email-masked]>

Eliot Lear wrote:
> Bernard Desruisseaux wrote:
>> Hi Eliot,
>>
>> Your proposal doesn't take into account the existing
>> Section 6 "Registration of Content Type Elements".
>>
>> We should either:
>>
>> 1- Extend this section to contain all templates.
>> 2- Move this section *in* the IANA Considerations section.
> 
> I think it was intended for (2), Bernard (insert in front of existing 
> text).  I'm sorry if I didn't make that clear.  It wasn't a great "diff".

I'm okay to move section 6 into the IANA Considerations section.

>> Also, I think we should consider having 4 templates:
>>
>> - Registration of New Components
>> - Registration of New Properties
>> - Registration of New Parameters
>> - Registration of New Values
>>
>> What do you think?
> 
> I think there needs to be a substantial difference in the templates to 
> justify four of them.  Do you think there is?

Here's what I have in mind.  A total of 5 templates.

   - Registration Template for New Components
   - Registration Template for New Properties
   - Registration Template for New Parameters
   - Registration Template for New Value Data Types
   - Registration Template for New Values

X.X.X  Registration Template for New Components

     A component is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar component XXX

         Component Name:

         Purpose:

         Format Definition:

         Description:

         Example:

X.X.X  Registration Template for New Properties

     A property is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar property XXX

         Property name:

         Purpose:

         Value type(s):

         Property parameter(s):

         Conformance:

         Description:

         Format definition:

         Example(s):

X.X.X  Registration Template for New Parameters

    A parameter is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar parameter XXX

         Parameter Name:

         Purpose:

         Format Definition:

         Description:

         Example(s):

X.X.X  Registration Template for New Value Data Types

    A value data type is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar value type XXX

         Value Name:

         Purpose:

         Format Definition:

         Description:

         Example(s):

X.X.X  Registration Template for New Values

    A value is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of iCalendar value XXX

         Value:

         Conformance:

         Example(s):

Everybody should be familiar with the first four templates as
there are numerous examples of their use in RFC2445. As for the
last template, here's a fictitious example:

         To: [email-masked]

         Subject: Registration of iCalendar value TOP-SECRET

         Value: TOP-SECRET

         Conformance: This value can be used with the CLASS
            property.

         Example(s):

            CLASS:TOP-SECRET

Cheers,
Bernard

Date: Wed, 20 Jun 2007 14:56:54 +0200
From: Eliot Lear <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
Cc: Eliot Lear <[email-masked]>, "[email-masked]" <[email-masked]>

Alexey Melnikov wrote:
>>>
>>> <t>
>>>    This section contains initial registrations for various protocol
>>>    elements specified in this memo, as well as a table that explains
>>>    what is required to add a new element.  Changing or removing an
>>>    existing element requires a standards action.
>>
> I disagree about removing existing elements. An element must never be 
> removed, it should be marked as "obsolete" instead.

You are, of course, correct.  Replace word "removing" with "obsoleting".

Date: Wed, 20 Jun 2007 13:52:05 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
Cc: "[email-masked]" <[email-masked]>

Bernard Desruisseaux wrote:

> Hi Eliot,
>
> Your proposal doesn't take into account the existing
> Section 6 "Registration of Content Type Elements".
>
> We should either:
>
> 1- Extend this section to contain all templates.
> 2- Move this section *in* the IANA Considerations section.
> 3- Move this section *after* the IANA Considerations section.

IANA likes templates and all initial registrations to be subsections of 
a single top level section called "IANA considerations".
It is Ok to register things in other places, as long as the IANA 
considerations section contains pointers to relevant sections.

> Also, I think we should consider having 4 templates:
>
> - Registration of New Components
> - Registration of New Properties
> - Registration of New Parameters
> - Registration of New Values
>
> What do you think?

We can and should have 4 templates if they are sufficiently different.
In general I prefer separate templates, as it is easier to read (and 
this will also make IANA's job easier, as IANA people get occasionally 
confused by complex templates).

> Cheers,
> Bernard
>
> Eliot Lear wrote:
>
>> Hi,
>>
>> Apologies for this being in XML, but it is intended for insertion.  I 
>> propose the following be inserted at the top of the IANA 
>> Considerations section.
>>
>>
>> <t>
>>    This section contains initial registrations for various protocol
>>    elements specified in this memo, as well as a table that explains
>>    what is required to add a new element.  Changing or removing an
>>    existing element requires a standards action.
>
I disagree about removing existing elements. An element must never be 
removed, it should be marked as "obsolete" instead.

>>   In order to add
>>    a new element, where marked "RFC", that specification MUST
>>    make use of the following template:
>> </t>
>> <figure>
>> <artwork>
>> <![CDATA[
>>
>>    Protocol Element Type:
>>    (e.g., Component, Property, Property Parameter, etc)
>>    Protocol element name:
>>    (MUST NOT begin with "X-")
>>    Short Description:
>>    (What it is)
>>    Long Description:
>>    In what contexts are the element valid?
>>    (Specify, for instance, where a property would be valid)
>>    Does this protocol element modify other existing elements?
>>    If so, describe:
>>    (For example, if a property parameter, how does it modify the
>>    property?)
>>
>> ]]></artwork>
>> </figure>
>> <t>
>>    Each answer MAY contain a normative reference.  No default values
>>    are allowed for properties or parameters.  Implementations that
>>    make use of a new protocol element MUST assume that they will
>>    interact with implementations that do not understand it.
>> </t>
>>
>
>

Date: Wed, 20 Jun 2007 07:48:47 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
Cc: Eliot Lear <[email-masked]>, "[email-masked]" <[email-masked]>

Bernard Desruisseaux wrote:
> Hi Eliot,
>
> Your proposal doesn't take into account the existing
> Section 6 "Registration of Content Type Elements".
>
> We should either:
>
> 1- Extend this section to contain all templates.
> 2- Move this section *in* the IANA Considerations section.

I think it was intended for (2), Bernard (insert in front of existing 
text).  I'm sorry if I didn't make that clear.  It wasn't a great "diff". 

> Also, I think we should consider having 4 templates:
>
> - Registration of New Components
> - Registration of New Properties
> - Registration of New Parameters
> - Registration of New Values
>
> What do you think?

I think there needs to be a substantial difference in the templates to 
justify four of them.  Do you think there is?

Eliot

Date: Tue, 19 Jun 2007 20:21:46 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: additional IANA considerations

Hi Eliot,

Your proposal doesn't take into account the existing
Section 6 "Registration of Content Type Elements".

We should either:

1- Extend this section to contain all templates.
2- Move this section *in* the IANA Considerations section.
3- Move this section *after* the IANA Considerations section.

Also, I think we should consider having 4 templates:

- Registration of New Components
- Registration of New Properties
- Registration of New Parameters
- Registration of New Values

What do you think?

Cheers,
Bernard

Eliot Lear wrote:
> Hi,
> 
> Apologies for this being in XML, but it is intended for insertion.  I 
> propose the following be inserted at the top of the IANA Considerations 
> section.
> 
> 
> <t>
>    This section contains initial registrations for various protocol
>    elements specified in this memo, as well as a table that explains
>    what is required to add a new element.  Changing or removing an
>    existing element requires a standards action.  In order to add
>    a new element, where marked "RFC", that specification MUST
>    make use of the following template:
> </t>
> <figure>
> <artwork>
> <![CDATA[
> 
>    Protocol Element Type:
>    (e.g., Component, Property, Property Parameter, etc)
>    Protocol element name:
>    (MUST NOT begin with "X-")
>    Short Description:
>    (What it is)
>    Long Description:
>    In what contexts are the element valid?
>    (Specify, for instance, where a property would be valid)
>    Does this protocol element modify other existing elements?
>    If so, describe:
>    (For example, if a property parameter, how does it modify the
>    property?)
> 
> ]]></artwork>
> </figure>
> <t>
>    Each answer MAY contain a normative reference.  No default values
>    are allowed for properties or parameters.  Implementations that
>    make use of a new protocol element MUST assume that they will
>    interact with implementations that do not understand it.
> </t>
> 

Date: Mon, 18 Jun 2007 09:25:10 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] additional IANA considerations

Hi,

Apologies for this being in XML, but it is intended for insertion.  I 
propose the following be inserted at the top of the IANA Considerations 
section.

<t>
    This section contains initial registrations for various protocol
    elements specified in this memo, as well as a table that explains
    what is required to add a new element.  Changing or removing an
    existing element requires a standards action.  In order to add
    a new element, where marked "RFC", that specification MUST
    make use of the following template:
</t>
<figure>
<artwork>
<![CDATA[

    Protocol Element Type:
    (e.g., Component, Property, Property Parameter, etc)
    Protocol element name:
    (MUST NOT begin with "X-")
    Short Description:
    (What it is)
    Long Description:
    In what contexts are the element valid?
    (Specify, for instance, where a property would be valid)
    Does this protocol element modify other existing elements?
    If so, describe:
    (For example, if a property parameter, how does it modify the
    property?)

]]></artwork>
</figure>
<t>
    Each answer MAY contain a normative reference.  No default values
    are allowed for properties or parameters.  Implementations that
    make use of a new protocol element MUST assume that they will
    interact with implementations that do not understand it.
</t>

Date: Sat, 16 Jun 2007 21:26:22 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] NOMCOM

As you probably know, IETF chooses its leadership through the NOMCOM 
process.  In order for that process to work properly we need eligible 
members of the IETF community to volunteer to serve on the NOMCOM 
committee.  While NOMCOM does take some time, you get what you deserve 
if you leave the choice of leadership to others.  And so I urge you to 
volunteer.  Please see below on how to do that.

Thanks,

Eliot

From: Lakshminath Dondeti
To: IETF Announcement
Date: June 4, 2007
Subject: Nomcom 2007-8: First Call for Volunteers

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

Folks,

If you have attended 3 out of the past 5 IETF meetings, you are eligible to
serve on Nomcom 2007-2008.  Please volunteer and you may become one of the
voting members of the committee that selects about half of the members to the
IESG and IAB and one IAOC member.  RFC 3777 describes the process and the
responsibilities in detail.  Below is the list of people from the IESG, IAB and
IAOC whose terms end during the March 2008 IETF meeting.

IAOC:

Ed Juskevicius

IAB:

Leslie Daigle
Elwyn Davies
Kevin Fall
Olaf Kolkman
David Oran
Eric Rescorla

IESG:

Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area
Director Dan Romascanu -- Operations and Management Area Director Cullen
Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon
--- Routing Area Director Sam Hartman -- Security Area Director Magnus
Westerlund -- Transport Area Director

Before volunteering, please think about whether you want to be considered for
one of those positions instead.  If you are already convinced, please send an
email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please
read on)

To: [email-masked]
Subject: Nomcom 2007-8 Volunteer
Body:

<Your Full Name>   // As you enter in the IETF Registration Form,
                           // First/Given name followed by Last/Family Name
<Current Primary Affiliation> // typically what goes in the Company field
                                          //  in the IETF Registration Form
[<all email addresses used to Register for the past 5 IETF meetings>] <Preferred
email address>  //
<Telephone number>         // For confirmation if selected

Please expect an email response from me within 1-2 days stating whether you are
qualified or not.  If you don't receive anything, please re-send your email with
the tag (duplicate) in the subject line.

Not convinced yet?  Please consider that nomcom members play an important role
in shaping the leadership of the IETF.  If you are a people person, you will
enjoy meeting many of the active contributors to the IETF.  If you prefer
instead to read a lot of email, well, we have that too.  Being a nomcom member
is also an important responsibility: it requires adherence to confidentiality
rules and some time commitment from the members.  The term begins just prior to
the Chicago meeting and we expect most of the work to be completed by January
2008.  During this period, the nomcom members

-- collect requirements from the community and interviews candidates
     during the Chicago and Vancouver IETF meetings
-- review candidates' statements and weighs community feedback
-- participate in candidate selection deliberations (weekly conferences
calls)

Nomcom members are selected following a publicly verifiable random selection
method specified in RFC 3797.

For the nomcom to work as it should, the pool from which the volunteers are
chosen should be as large as possible. The more people who volunteer, the better
chance we have of choosing a random yet representative cross section of the IETF
population.

Ensuring the leadership of the IETF is fair and balanced and comprised of those
who can lead the IETF in the right direction is an important responsibility that
rests on the IETF participants at large.  Volunteering for the nomcom is a good
way of contributing in that direction.  So please volunteer!

thanks,
Lakshminath

Date: Thu, 14 Jun 2007 14:52:24 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Reminder: Jabber chat today at 4:00pm CEDT / 10:00am EDT / 7:00am PDT

Hi,

Address is [email-masked].

On the agenda:

- finishing up rfc2445bis and closing its remaining issues
- moving on to rfc2446bis issues

See you there!

Cheers,
Aki

Date: Thu, 14 Jun 2007 12:47:20 +0300
From: Aki Niemi <[email-masked]>
To: ext Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 80: security considerations section -- proposal
Cc: [email-masked]

ext Reinhold Kainhofer wrote:
>> This is a point that has been discussed a lot. It is true that RFC2119
>> text should only be used when there is an actual implementation choice
>> that is observable from the outside. Here, I agree that a "MUST" is just
>> hand-waiving, so I'm ok making it a "must" instead.
> 
> I think it's rather a SHOULD (or a should?). It'a really up to the groupware 
> server developers/designers and out of scope for the data format definition. 
> If a server team has good reasons against implementing some security measure, 
> it's their business, not ours.

Yes, agree. And this is why it says capabilities. It's always in the 
admin's or user's discretion whether to turn them on.

Cheers,
Aki

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 80: security considerations section =?iso-8859-1?q?--=09proposal?=
Date: Thu, 14 Jun 2007 10:00:58 +0200

Am Donnerstag, 14. Juni 2007 schrieb Aki Niemi:
> Hi Oliver,
>
> This is a point that has been discussed a lot. It is true that RFC2119
> text should only be used when there is an actual implementation choice
> that is observable from the outside. Here, I agree that a "MUST" is just
> hand-waiving, so I'm ok making it a "must" instead.

I think it's rather a SHOULD (or a should?). It'a really up to the groupware 
server developers/designers and out of scope for the data format definition. 
If a server team has good reasons against implementing some security measure, 
it's their business, not ours.

Cheers, 
Reinhold

> > Am Dienstag, 12. Juni 2007 09:54 schrieb Aki Niemi:
> >>    <p>
> >>      Because calendaring and scheduling information is very
> >>      privacy-sensitive, the protocol used for the transmission of
> >>      calendaring and scheduling information MUST have capabilities to
> >>      protect the information from possible threats, such as
> >>      eavesdropping, replay, message insertion, deletion, modification
> >>      and man-in-the-middle attacks.
> >>    </p>

- -- 
- ------------------------------------------------------------------
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, 14 Jun 2007 10:24:00 +0300
From: Aki Niemi <[email-masked]>
To: ext Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 80: security considerations section --	proposal
Cc: [email-masked]

Hi Oliver,

This is a point that has been discussed a lot. It is true that RFC2119 
text should only be used when there is an actual implementation choice 
that is observable from the outside. Here, I agree that a "MUST" is just 
hand-waiving, so I'm ok making it a "must" instead.

Cheers,
Aki

ext Oliver Block wrote:
> Hello Aki,
> 
> even though I like your proposal and to know that my calendar data is safe, Is 
> the MUST admissible in this context?
> 
> <copy src="rfc2119">
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> </copy>
> 
> Regards,
> 
> Oliver
> 
> Am Dienstag, 12. Juni 2007 09:54 schrieb Aki Niemi:
>> In one of the recent Jabber chats, I promised to take a stab at new text
>> for the section. Here's the proposal:
>>
>> <section title='Security Considerations'>
>>
>>    <p>
>>      Because calendaring and scheduling information is very
>>      privacy-sensitive, the protocol used for the transmission of
>>      calendaring and scheduling information MUST have capabilities to
>>      protect the information from possible threats, such as
>>      eavesdropping, replay, message insertion, deletion, modification
>>      and man-in-the-middle attacks.
>>    </p>
>>
>>    <p>
>>      As this document only defines the data format and media type of
>>      text/calendar that is independent of any calendar service or
>>      protocol, it is up to the actual protocol specifications such as
>>      <xref target="I-D.xxx">iTIP</xref>, <xref
>>      target="I-D.xxx">iMIP</xref> and <xref
>>      target="RFC4791">CalDAV</xref> to describe the threats that the
>>      above attacks present, as well as ways in which to mitigate them.
>>    </p>
>>
>> In other words, rfc2445bis would now be completely silent about
>> authorization issues, and instead move responsibility over to actual
>> calendaring protocols and/or services. I'll note that a similar approach
>> has been taken in at least in RFC3863, Presence Information Data Format
>> (PIDF).
>>
>> Any opinions?
>>
>> Cheers,
>> Aki
>> (as individual contributor)

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 80: security considerations section -- proposal
Date: Wed, 13 Jun 2007 22:10:45 +0200

Hello Aki,

even though I like your proposal and to know that my calendar data is safe, Is 
the MUST admissible in this context?

<copy src="rfc2119">
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
</copy>

Regards,

Oliver

Am Dienstag, 12. Juni 2007 09:54 schrieb Aki Niemi:
> In one of the recent Jabber chats, I promised to take a stab at new text
> for the section. Here's the proposal:
>
> <section title='Security Considerations'>
>
>    <p>
>      Because calendaring and scheduling information is very
>      privacy-sensitive, the protocol used for the transmission of
>      calendaring and scheduling information MUST have capabilities to
>      protect the information from possible threats, such as
>      eavesdropping, replay, message insertion, deletion, modification
>      and man-in-the-middle attacks.
>    </p>
>
>    <p>
>      As this document only defines the data format and media type of
>      text/calendar that is independent of any calendar service or
>      protocol, it is up to the actual protocol specifications such as
>      <xref target="I-D.xxx">iTIP</xref>, <xref
>      target="I-D.xxx">iMIP</xref> and <xref
>      target="RFC4791">CalDAV</xref> to describe the threats that the
>      above attacks present, as well as ways in which to mitigate them.
>    </p>
>
> In other words, rfc2445bis would now be completely silent about
> authorization issues, and instead move responsibility over to actual
> calendaring protocols and/or services. I'll note that a similar approach
> has been taken in at least in RFC3863, Presence Information Data Format
> (PIDF).
>
> Any opinions?
>
> Cheers,
> Aki
> (as individual contributor)

Date: Wed, 13 Jun 2007 09:38:53 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Aki Niemi <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 80: security considerations section -- proposal
Cc: [email-masked]

+1

Aki Niemi wrote:
> Hi all,
> 
> A while back, Jay posted an issue about the security considerations of 
> rfc2445bis, which is tracked as issue 80.
> 
> In one of the recent Jabber chats, I promised to take a stab at new text 
> for the section. Here's the proposal:
> 
> <section title='Security Considerations'>
> 
>   <p>
>     Because calendaring and scheduling information is very
>     privacy-sensitive, the protocol used for the transmission of
>     calendaring and scheduling information MUST have capabilities to
>     protect the information from possible threats, such as
>     eavesdropping, replay, message insertion, deletion, modification
>     and man-in-the-middle attacks.
>   </p>
> 
>   <p>
>     As this document only defines the data format and media type of
>     text/calendar that is independent of any calendar service or
>     protocol, it is up to the actual protocol specifications such as
>     <xref target="I-D.xxx">iTIP</xref>, <xref
>     target="I-D.xxx">iMIP</xref> and <xref
>     target="RFC4791">CalDAV</xref> to describe the threats that the
>     above attacks present, as well as ways in which to mitigate them.
>   </p>
> 
> In other words, rfc2445bis would now be completely silent about 
> authorization issues, and instead move responsibility over to actual 
> calendaring protocols and/or services. I'll note that a similar approach 
> has been taken in at least in RFC3863, Presence Information Data Format 
> (PIDF).
> 
> Any opinions?
> 
> Cheers,
> Aki
> (as individual contributor)

Date: Wed, 13 Jun 2007 09:41:26 +0300
From: Aki Niemi <[email-masked]>
To: ext Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] I18n considerations section in rfc2445bis
Cc: [email-masked]

ext Reinhold Kainhofer wrote:
>>      All the implementations of iCalendar conformant to this
>>      specification MUST generate UTF-8 and accept either UTF-8 or
>>      US-ASCII encoding.
> 
> Hmm, isn't US-ASCII a subset of UTF-8? What's the exact meaning of the second 
> part? An Implementation that only accepts US-ASCII is worthless, as it breaks 
> with all international characters (German umlaute, French accents, the 
> Spanish ñ, etc.), and should not be considered conformant in my opinion. And 
> an implementation that accepts UTF-8 automatically accepts US-ASCII.

This text was supposed to merely point out in summary what the 
specification says elsewhere. Namely that UTF-8 is the default charset, 
but implementations must also accept iCalendar objects whose MIME type 
has s charset=us-ascii parameter.

I'd welcome suggestions for better wording; I realize this is important 
to get right and definitely don't want this sections to say anything 
contradictory to the main body of text.

Cheers,
Aki

Date: Tue, 12 Jun 2007 10:32:47 -0700
From: "Mike Samuel" <[email-masked]>
To: "Reinhold Kainhofer" <[email-masked]>
Subject: Re: [Ietf-calsify] I18n considerations section in rfc2445bis
Cc: [email-masked]
Reply-To: [email-masked]

How many projects out there support unicode pages 0x100000 - 0x10ffff?

Do most of the java projects out there support proper UTF-8 or will
they UTF-16 encode codepoints >=3D 0x10000 the way java.lang.String
does?

mike

On 12/06/07, Reinhold Kainhofer <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Dienstag, 12. Juni 2007 schrieb Aki Niemi:
> > The current rfc2445bis draft has an internationalization considerations
> > section but it's empty. How about:
> >
> > <section title=3D'Internationalization Considerations'>
> >
> >    <p>
> >      All the implementations of iCalendar conformant to this
> >      specification MUST generate UTF-8 and accept either UTF-8 or
> >      US-ASCII encoding.
>
> Hmm, isn't US-ASCII a subset of UTF-8? What's the exact meaning of the se=
cond
> part? An Implementation that only accepts US-ASCII is worthless, as it br=
eaks
> with all international characters (German umlaute, French accents, the
> Spanish =F1, etc.), and should not be considered conformant in my opinion=
. And
> an implementation that accepts UTF-8 automatically accepts US-ASCII.
>
>
> 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.6 (GNU/Linux)
>
> iD8DBQFGbm0ZTqjEwhXvPN0RAjRZAJ9EAvz4HthAM12kMsfFZtT6Bx8NgwCgic0A
> 2zvTAATl17vCAnNbsi2o77k=3D
> =3Ddcvn
> -----END PGP SIGNATURE-----

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] I18n considerations section in rfc2445bis
Date: Tue, 12 Jun 2007 11:53:24 +0200

Am Dienstag, 12. Juni 2007 schrieb Aki Niemi:
> The current rfc2445bis draft has an internationalization considerations
> section but it's empty. How about:
>
> <section title='Internationalization Considerations'>
>
>    <p>
>      All the implementations of iCalendar conformant to this
>      specification MUST generate UTF-8 and accept either UTF-8 or
>      US-ASCII encoding.

Hmm, isn't US-ASCII a subset of UTF-8? What's the exact meaning of the second 
part? An Implementation that only accepts US-ASCII is worthless, as it breaks 
with all international characters (German umlaute, French accents, the 
Spanish ñ, etc.), and should not be considered conformant in my opinion. And 
an implementation that accepts UTF-8 automatically accepts US-ASCII.

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: Tue, 12 Jun 2007 12:05:19 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] I18n considerations section in rfc2445bis

Hi all,

The current rfc2445bis draft has an internationalization considerations 
section but it's empty. How about:

<section title='Internationalization Considerations'>

   <p>
     All the implementations of iCalendar conformant to this
     specification MUST generate UTF-8 and accept either UTF-8 or
     US-ASCII encoding.
   </p>

</section>

Cheers,
Aki
(as individual contributor)

Date: Tue, 12 Jun 2007 10:54:52 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Issue 80: security considerations section -- proposal

Hi all,

A while back, Jay posted an issue about the security considerations of 
rfc2445bis, which is tracked as issue 80.

In one of the recent Jabber chats, I promised to take a stab at new text 
for the section. Here's the proposal:

<section title='Security Considerations'>

   <p>
     Because calendaring and scheduling information is very
     privacy-sensitive, the protocol used for the transmission of
     calendaring and scheduling information MUST have capabilities to
     protect the information from possible threats, such as
     eavesdropping, replay, message insertion, deletion, modification
     and man-in-the-middle attacks.
   </p>

   <p>
     As this document only defines the data format and media type of
     text/calendar that is independent of any calendar service or
     protocol, it is up to the actual protocol specifications such as
     <xref target="I-D.xxx">iTIP</xref>, <xref
     target="I-D.xxx">iMIP</xref> and <xref
     target="RFC4791">CalDAV</xref> to describe the threats that the
     above attacks present, as well as ways in which to mitigate them.
   </p>

In other words, rfc2445bis would now be completely silent about 
authorization issues, and instead move responsibility over to actual 
calendaring protocols and/or services. I'll note that a similar approach 
has been taken in at least in RFC3863, Presence Information Data Format 
(PIDF).

Any opinions?

Cheers,
Aki
(as individual contributor)

Date: Thu, 07 Jun 2007 14:37:36 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: calsify jabber session starts at 4:00pm CEDT / 10:00am EDT / 7:00am PDT

[email-masked].

Date: Thu, 07 Jun 2007 10:02:35 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] [Fwd: [IANA #79134] Early Review of draft-ietf-calsify-rfc2445bis]

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

FYI - perhaps for discussion on today's jabber?

--------------000906010006090303090704
Content-Type: message/rfc822;
	name="[IANA #79134] Early Review of draft-ietf-calsify-rfc2445bis.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename*0="[IANA #79134] Early Review of
	draft-ietf-calsify-rfc2445bis."; filename*1="eml"

Subject: [IANA #79134] Early Review of draft-ietf-calsify-rfc2445bis 
From: "Michelle Cotton via RT" <[email-masked]>
Reply-To: [email-masked]
RT-Ticket: IANA #79134
Managed-by: RT 3.5.HEAD (http://www.bestpractical.com/rt/)
RT-Originator: [email-masked]
Cc: [email-masked]
Date: Wed, 06 Jun 2007 13:03:44 -0700

Eliot,

Apologies for the delay in getting this information to you.  Your document has been reviewed.
Our reviewer had the following comments (see below).  We hope you find this information helpful.
We had created this ticket to make sure that this request was completed.  I'm closing this ticket at this 
time as we have provided early feedback.

IANA will also review the document when it goes through IESG Last Call.

Thank you,

Michelle Cotton
IANA

IANA has Questions..

In general the IANA Considerations in this document is superb.
However there are still a few open questions.

The main IANA Considerations (section 9) lays out the set of
sub-registries to get created (see table below) but doesn't
suggest a name of the overarching calendar registry.

QUESTION: What should be the name of this overarching registry?
Should it be "iCalendar Parameters" or something else?

The document then lays out twelve additional actions for IANA,
summerized by the following table (plus an additional mime-type
registration) and then clearly enumerated in the following sections:

+---------------+------------------------------------+--------------+
| Registry Name | Registration Requirements | Reference |
+---------------+------------------------------------+--------------+
| Components | RFC, Expert Review | Section 9.1 |
| Properties | RFC, Expert Review | Section 9.2 |
| Property | RFC, Expert Review | Section 9.3 |
| Parameters | | |
| Value Data | Standards Action Required for new | Section 9.4 |
| Type Values | values that modify existing | |
| | parameters | |
| Calendar User | RFC, Expert Review | Section 9.5 |
| Type Values | | |
| Free/Busy | RFC, Expert Review | Section 9.6 |
| Time Type | | |
| Values | | |
| Participation | Internet Standards Action for | Section 9.7 |
| Status Values | VEVENTs, otherwise Expert Review | |
| Relationship | RFC, Expert Review | Section 9.8 |
| Type Values | | |
| Participation | RFC, Expert Review | Section 9.9 |
| Role Values | | |
| Action Values | RFC, Expert Review | Section 9.10 |
| Method Values | RFC, Expert Review | Section 9.11 |
+---------------+------------------------------------+--------------+

9.1. Components Registry

The following table is to be used to initialize the components
registry.

+----------------+---------+------------------------+
| Component Name | Status | Reference |
+----------------+---------+------------------------+
| VCALENDAR | Current | RFCXXXX, Section 3.4 |
| VEVENT | Current | RFCXXXX, Section 3.6.1 |
| VTODO | Current | RFCXXXX, Section 3.6.2 |
| VJOURNAL | Current | RFCXXXX, Section 3.6.3 |
| VFREEBUSY | Current | RFCXXXX, Section 3.6.4 |
| VTIMEZONE | Current | RFCXXXX, Section 3.6.5 |
| VALARM | Current | RFCXXXX, Section 3.6.6 |
| STANDARD | Current | RFCXXXX, Section 3.6.5 |
| DAYLIGHT | Current | RFCXXXX, Section 3.6.5 |
+----------------+---------+------------------------+

9.2. Properties Registry

Properties that are registered with IANA are to be document via the
RFC process. It is not necessary for properties to be placed on the
standards track to be registered unless the usage of other standard
properties, parameters, or enumerations are changed. Components
specifically require standards action. However, each property MUST
specify what standard parameters, if any, are allowed, and in what
components the property is valid (e.g., "VEVENT", "VTODO", etc.).
The IANA is requested to maintain a table of such properties with
pointers to appropriate reference documents.

The following table is to be used to initialize the property
registry.

+------------------+------------+---------------------------+
| Property Name | Status | Reference |
+------------------+------------+---------------------------+
| CALSCALE | Current | RFCXXXX, Section 3.7.1 |
| METHOD | Current | RFCXXXX, Section 3.7.2 |
| PRODID | Current | RFCXXXX, Section 3.7.3 |
| VERSION | Current | RFCXXXX, Section 3.7.4 |
| ATTACH | Current | RFCXXXX, Section 3.8.1.1 |
| CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 |
| CLASS | Current | RFCXXXX, Section 3.8.1.3 |
| COMMENT | Current | RFCXXXX, Section 3.8.1.4 |
| DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 |
| GEO | Current | RFCXXXX, Section 3.8.1.6 |
| LOCATION | Current | RFCXXXX, Section 3.8.1.7 |
| PERCENT-COMPLETE | Current | RFCXXXX, Section 3.8.1.8 |
| PRIORITY | Current | RFCXXXX, Section 3.8.1.9 |
| RESOURCES | Current | RFCXXXX, Section 3.8.1.10 |
| STATUS | Current | RFCXXXX, Section 3.8.1.11 |
| SUMMARY | Current | RFCXXXX, Section 3.8.1.12 |
| COMPLETED | Current | RFCXXXX, Section 3.8.2.1 |
| DTEND | Current | RFCXXXX, Section 3.8.2.2 |
| DUE | Current | RFCXXXX, Section 3.8.2.3 |
| DTSTART | Current | RFCXXXX, Section 3.8.2.4 |
| DURATION | Current | RFCXXXX, Section 3.8.2.5 |
| FREEBUSY | Current | RFCXXXX, Section 3.8.2.6 |
| TRANSP | Current | RFCXXXX, Section 3.8.2.7 |
| TZID | Current | RFCXXXX, Section 3.8.3.1 |
| TZNAME | Current | RFCXXXX, Section 3.8.3.2 |
| TZOFFSETFROM | Current | RFCXXXX, Section 3.8.3.3 |
| TZOFFSETTO | Current | RFCXXXX, Section 3.8.3.4 |
| TZURL | Current | RFCXXXX, Section 3.8.3.5 |
| ATTENDEE | Current | RFCXXXX, Section 3.8.4.1 |
| CONTACT | Current | RFCXXXX, Section 3.8.4.2 |
| ORGANIZER | Current | RFCXXXX, Section 3.8.4.3 |
| RECURRENCE-ID | Current | RFCXXXX, Section 3.8.4.4 |
| RELATED-TO | Current | RFCXXXX, Section 3.8.4.5 |
| URL | Current | RFCXXXX, Section 3.8.4.6 |
| UID | Current | RFCXXXX, Section 3.8.4.7 |
| EXDATE | Current | RFCXXXX, Section 3.8.5.1 |
| EXRULE | Deprecated | RFC2445, Section 4.8.5.2 |
| RDATE | Current | RFCXXXX, Section 3.8.5.2 |
| RRULE | Current | RFCXXXX, Section 3.8.5.3 |
| ACTION | Current | RFCXXXX, Section 3.8.6.1 |
| REPEAT | Current | RFCXXXX, Section 3.8.6.2 |
| TRIGGER | Current | RFCXXXX, Section 3.8.6.3 |
| CREATED | Current | RFCXXXX, Section 3.8.7.1 |
| DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 |
| LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 |
| SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 |
| REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 |
+------------------+------------+---------------------------+

QUESTION: what about the request-status values (section 3.8.8.3)? Do
you want/need a registry for potential values for this property? In
particular do you want to make sure that status codes are not re-used
across different responses?

9.3. Property Parameters Registry

The IANA is requested to establish and maintain a table of property
parameters for the iCalendar standard. Additional parameters may be
added to this table as follows:

o Those parameters that do not modify standard properties or
parameters may be added through the publishing of informational or
experimental RFCs with expert review through the APPS Area of the
IETF.

o Those property parameters that modify existing standard properties
or parameters MUST update this memo, and hence be promoted through
the Internet standards process.

In all cases, each parameter MUST list the property it will be used
with. Implementations that are unable to recognize a property
parameter MUST ignore the property.

The following table is to be initialized with the following values:

+-------------------------+------------+-------------------------+
| Property Parameter Name | Status | Reference |
+-------------------------+------------+-------------------------+
| ALTREP | Current | RFCXXXX, Section 3.2.1 |
| CN | Current | RFCXXXX, Section 3.2.2 |
| CUTYPE | Current | RFCXXXX, Section 3.2.3 |
| DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 |
| DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 |
| DIR | Current | RFCXXXX, Section 3.2.6 |
| ENCODING | Current | RFCXXXX, Section 3.2.7 |
| FMTTYPE | Current | RFCXXXX, Section 3.2.8 |
| FBTYPE | Current | RFCXXXX, Section 3.2.9 |
| LANGUAGE | Current | RFCXXXX, Section 3.2.10 |
| MEMBER | Current | RFCXXXX, Section 3.2.11 |
| PARTSTAT | Current | RFCXXXX, Section 3.2.12 |
| RANGE | Deprecated | RFC2445, Section 4.2.13 |
| RELATED | Current | RFCXXXX, Section 3.2.13 |
| RELTYPE | Current | RFCXXXX, Section 3.2.14 |
| ROLE | Current | RFCXXXX, Section 3.2.15 |
| RSVP | Current | RFCXXXX, Section 3.2.16 |
| SENT-BY | Current | RFCXXXX, Section 3.2.17 |
| TZID | Current | RFCXXXX, Section 3.2.18 |
| VALUE | Current | RFCXXXX, Section 3.2.19 |
+-------------------------+------------+-------------------------+

9.4. Value Data Type Values Registry

The IANA is requested to establish a registry of Property Value Data
Types for the iCalendar standard. Additional data types may only be
added through the Internet standards process. The initial values are
as follows:

+-------------------------------+---------+-------------------------+
| Property Parameter Value Type | Status | Reference |
+-------------------------------+---------+-------------------------+
| BINARY | Current | RFCXXXX, Section 3.3.1 |
| BOOLEAN | Current | RFCXXXX, Section 3.3.2 |
| CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 |
| DATE | Current | RFCXXXX, Section 3.3.4 |
| DATE-TIME | Current | RFCXXXX, Section 3.3.5 |
| DURATION | Current | RFCXXXX, Section 3.3.6 |
| FLOAT | Current | RFCXXXX, Section 3.3.7 |
| INTEGER | Current | RFCXXXX, Section 3.3.8 |
| PERIOD | Current | RFCXXXX, Section 3.3.9 |
| RECUR | Current | RFCXXXX, Section 3.3.10 |
| TEXT | Current | RFCXXXX, Section 3.3.11 |
| TIME | Current | RFCXXXX, Section 3.3.12 |
| URI | Current | RFCXXXX, Section 3.3.13 |
| UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 |
+-------------------------------+---------+-------------------------+

QUESTION: what about the contents of recur-rule-part? Do you want
a registry of the values in the RECUR rule (section 3.3.10)? Are
there other potential things that could go into this entry or is
this truly a fixed list?

9.5. Calendar User Type Values Registry

Calendar user types (CUTYPEs) are used to indicate the sort of user
associated with a CAL-ADDRESS. It is described in more detail in
Section 3.2.3. Expert review is required for an IANA assignment.
The following values are currently allowed:

+--------------------+---------+------------------------+
| Calendar User Type | Status | Reference |
+--------------------+---------+------------------------+
| INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 |
| GROUP | Current | RFCXXXX, Section 3.2.3 |
| RESOURCE | Current | RFCXXXX, Section 3.2.3 |
| ROOM | Current | RFCXXXX, Section 3.2.3 |
| UNKNOWN | Current | RFCXXXX, Section 3.2.3 |
+--------------------+---------+------------------------+

Implementations that do not recognize a calendar user type MUST treat
the CAL-ADDRESS as an INDIVIDUAL.

9.6. Free/Busy Time Type Values Registry

This parameter is described in Section 3.2.9. New entries require
expert review. The table below specifies the initial registry:

+------------------+---------+------------------------+
| Free/Busy Type | Status | Reference |
+------------------+---------+------------------------+
| FREE | Current | RFCXXXX, Section 3.2.9 |
| BUSY | Current | RFCXXXX, Section 3.2.9 |
| BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 |
| BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 |
+------------------+---------+------------------------+

Implementations that do not recognize a particular fbtype MUST treat
that calendar user as BUSY.

9.7. Participation Status Values Registry

PARTSTAT denotes participate status and is described in
Section 3.2.12. The following table initializes the registry for
participant status:

+--------------------------+---------+-------------------------+
| Participant Status Value | Status | Reference |
+--------------------------+---------+-------------------------+
| NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 |
| ACCEPTED | Current | RFCXXXX, Section 3.2.12 |
| DECLINED | Current | RFCXXXX, Section 3.2.12 |
| TENTATIVE | Current | RFCXXXX, Section 3.2.12 |
| DELEGATED | Current | RFCXXXX, Section 3.2.12 |
| COMPLETED | Current | RFCXXXX, Section 3.2.12 |
| IN-PROCESS | Current | RFCXXXX, Section 3.2.12 |
+--------------------------+---------+-------------------------+

Existing implementations MUST treat an unknown PARTSTAT value as
NEEDS-ACTION.

9.8. Relationship Type Values Registry

This parameter is described in Section 3.2.14. Expert review is
required for an addition. The table below initializes the registry.

+-------------------+---------+-------------------------+
| Relationship Type | Status | Reference |
+-------------------+---------+-------------------------+
| CHILD | Current | RFCXXXX, Section 3.2.14 |
| PARENT | Current | RFCXXXX, Section 3.2.14 |
| SIBLING | Current | RFCXXXX, Section 3.2.14 |
+-------------------+---------+-------------------------+

Implementations MUST treat an unknown relationship as a PARENT.

9.9. Participation Role Values Registry

Roles are described in Section 3.2.15. The initial registration is
as follows:

+-----------------+---------+-------------------------+
| Role Type | Status | Reference |
+-----------------+---------+-------------------------+
| CHAIR | Current | RFCXXXX, Section 3.2.15 |
| REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
| OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
| NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
+-----------------+---------+-------------------------+

Implementations that do not recognize a specific ROLE should treat
the calendar user as REQ-PARTICIPANT.

9.10. Action Values Registry

Actions are covered in Section 3.8.6.1. The following table
intializes the registry.

+-----------------------+------------+--------------------------+
| ACTION Property Value | Status | Reference |
+-----------------------+------------+--------------------------+
| AUDIO | Current | RFCXXXX, Section 3.8.6.1 |
| DISPLAY | Current | RFCXXXX, Section 3.8.6.1 |
| EMAIL | Current | RFCXXXX, Section 3.8.6.1 |
| PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 |
+-----------------------+------------+--------------------------+

Implementations MUST ignore unrecognized "ACTION" property values.

9.11. Method Values Registry

Methods are covered in Section 3.7.2. No values are defined in this
document for the "METHOD" property.

9.12. Media Type Registration Information

The Calendaring and Scheduling Core Object Specification is intended
for use as a MIME content type. However, the implementation of the
memo is in no way limited solely as a MIME content type.

To: [email-masked]
Subject: Registration of media type text/calendar

Type name: text

Subtype name: calendar

Required parameters: none

Optional parameters: charset, method, component and optinfo

The "charset" parameter is defined in [RFC2046] for subtypes of
the "text" media type. It is used to indicate the charset used in
the body part. The charset supported by this revision of
iCalendar is UTF-8. The use of any other charset is deprecated by
this revision of iCalendar; however note that this revision
requires that compliant applications MUST accept iCalendar objects
using either the UTF-8 or US-ASCII charset.

The "method" parameter is used to convey the iCalendar object
method or transaction semantics for the calendaring and scheduling
information. It also is an identifier for the restricted set of
properties and values that the iCalendar object consists of. The
parameter is to be used as a guide for applications interpreting
the information contained within the body part. It SHOULD NOT be
used to exclude or require particular pieces of information unless
the identified method definition specifically calls for this
behavior. Unless specifically forbidden by a particular method
definition, a text/calendar content type can contain any set of
properties permitted by the Calendaring and Scheduling Core Object
Specification. The "method" parameter MUST be specified and MUST
be set to the same value as the "METHOD" component property of the
iCalendar objects of the iCalendar stream if and only if the
iCalendar objects in the iCalendar stream all have a "METHOD"
component property set to the same value.

The value for the "method" parameter is defined as follows:

method = 1*(ALPHA / DIGIT / "-")
; IANA registered iCalendar object method

The "component" parameter conveys the type of iCalendar calendar
component within the body part. If the iCalendar object contains
more than one calendar component type, then multiple component
parameters MUST be specified.

The value for the "component" parameter is defined as follows:

component = "VEVENT"
/ "VTODO"
/ "VJOURNAL"
/ "VFREEBUSY"
/ "VTIMEZONE"
/ iana-token
/ x-name

The "optinfo" parameter conveys optional information about the
iCalendar object within the body part. This parameter can only
specify semantics already specified by the iCalendar object and
that can be otherwise determined by parsing the body part. In
addition, the optional information specified by this parameter
MUST be consistent with that information specified by the
iCalendar object. For example, it can be used to convey the
"Attendee" response status to a meeting request. The parameter
value consists of a string value.

The parameter can be specified multiple times.

The value for the "optinfo" parameter is defined as follows:

optinfo = infovalue / qinfovalue

infovalue = iana-token / x-name

qinfovalue = DQUOTE (infovalue) DQUOTE

Encoding considerations: This media type can contain 8bit
characters, so the use of quoted-printable or base64 MIME Content-
Transfer-Encodings might be necessary when iCalendar objects are
transferred across protocols restricted to the 7bit repertoire.
Note that a text valued property in the content entity can also
have content encoding of special characters using a BACKSLASH
character (US-ASCII decimal 92) escapement technique. This means
that content values can end up encoded twice.

Security considerations: See Section 8.

Interoperability considerations: This media type is intended to
define a common format for conveying calendaring and scheduling
information between different systems. It is heavily based on the
earlier [VCAL] industry specification.

Published specification: This specification.

Applications which use this media type: This media type is designed
for widespread use by Internet calendaring and scheduling
applications. In addition, applications in the workflow and
document management area might find this content-type applicable.
The iTIP [I-D.ietf-calsify-2446bis], iMIP
[I-D.ietf-calsify-rfc2447bis] and CalDAV [I-D.dusseault-caldav]
Internet protocols directly use this media type also.

Additional information:

Magic number(s): None.

File extension(s): The file extension of "ics" is to be used to
designate a file containing (an arbitrary set of) calendaring
and scheduling information consistent with this MIME content
type.

The file extension of "ifb" is to be used to designate a file
containing free or busy time information consistent with this
MIME content type.

Macintosh file type code(s): The file type code of "iCal" is to
be used in Apple MacIntosh operating system environments to
designate a file containing calendaring and scheduling
information consistent with this MIME media type.

The file type code of "iFBf" is to be used in Apple MacIntosh
operating system environments to designate a file containing
free or busy time information consistent with this MIME media
type.

Person & email address to contact for further information: TBD

Intended usage: COMMON

Restrictions on usage: There are no restrictions on where this media
type can be used.

Author: TBD

Change controller: IETF

--------------000906010006090303090704--

Date: Tue, 5 Jun 2007 14:00:19 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <[email-masked]>
To: "Martin Kiff" <[email-masked]>
Subject: Re: [Ietf-calsify] Imprecise and alternative events
Cc: [email-masked]

------=_Part_19062_21242877.1181062819599
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Martin,

Thanks for the feedback!

Yes, that flexibility is what we aimed by allowing several VEVENT and
VIMPRECISEEVENT components within a VALTERNATIVEEVENTS. The example at page
9 illustrated it poorly, because it used only one VEVENT and only one
VIMPRECISEEVENT; we'll improve the draft that by adding other examples.

As for imprecise events, two complementary mechanisms are needed to:
1 - Express the expected duration of the event
2 - Express the possible time ranges for event occurrence

In our proposal, VIMPRECISEEVENT doesn't make use of DTSTART. (1) is done
with DURATION, and (2) is done by using VFREEBUSY and VAVAILABILITY
components.

As long as I understand, you are suggesting to extend DTSTART to accomplish
both (although it would be possible to have just one "time range" for 2). I
am not sure if that would have some impact on current use of DTSTART (e.g.,
free-busy queries). The idea of using concepts like 'evening' is really
interesting, but I am concerned with possible interoperability problems -
that's why we have opted for "deterministic" forms to represent periods of
time ("canonical" VFREEBUSY and VAVAILABILITY). I believe that those who
have long discussed issues with time representation on 2445bis can give a
definitive opinion on this.

Anyway, if we are to use extended VEVENT components to represent imprecise
events, a discussion on the role of DTSTART in this context is fundamental.

Regards,

F=E1bio.

On 6/3/07, Martin Kiff < [email-masked]> wrote:
>
> F=E1bio Henrique da Silva wrote:
>
> > Dear all,
> >
> > This is to announce the new internet-draft:
> >
> > < http://www.ietf.org/internet-drafts/draft-silva-events-00.txt>
>
>
> Interesting, I've read through once and will definitely read through
> again.
> I wonder whether it would go with the flow better to have a 'negotiate'
> block round a set of Vevents? Was this sort of option considered (and
> discarded?)
>
> BEGIN:ALTERNATES
>
> BEGIN:VEVENT
> PREFERENCE:100
> ...
> END:VEVENT
>
> BEGIN:VEVENT
> PREFERENCE:50
> TRANSP:TRANSPARENT
> ...
> END:VEVENT
>
> END:ALTERNATES
>
> This would give flexibility to have different locations, different
> descriptions (and so on) for the different options.
>
> For imprecise events, I think a lot of the the requirements when
> publishing (rather then negotiating) events would be covered by
> accepting varying precision in the time:
>   DTSTART:VALUE=3DHOUR:20070603T090000
> maybe for something that could start between 9 and 11.
>   DTSTART:VALUE=3DPT2H:20070603T090000
> and, if you know it's an evening (or whatever) event but don't know
> when...
>   DTSTART:VALUE=3DEVENING:20070603
>
> My arguments are based on the premises:
>
> * People don't necessarily work to second-level-precision, I don't think
> calendaring software should inflict this on them :-)
> * Calendaring has to keep a distinction between a 'whole day event'
> (like an anniversary) and an 'event on a day' (but you don't yet know
> when) and it would be nice if this could be generalised
>
> Regards, Martin
>
>
>

------=_Part_19062_21242877.1181062819599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Martin,<br><br>Thanks for the feedback!<br><br>Yes, that flexibility is =
what we aimed by allowing several VEVENT and VIMPRECISEEVENT components wit=
hin a VALTERNATIVEEVENTS. The example at page 9 illustrated it poorly, beca=
use it used only one VEVENT and only one VIMPRECISEEVENT; we&#39;ll improve=
 the draft that by adding other examples.
<br><br>As for imprecise events, two complementary mechanisms are needed to=
:<br>1 - Express the expected duration of the event<br>2 - Express the poss=
ible time ranges for event occurrence<br><br>In our proposal, VIMPRECISEEVE=
NT doesn&#39;t make use of DTSTART. (1) is done with DURATION, and (2) is d=
one by using VFREEBUSY and VAVAILABILITY components.
<br>
<br>As long as I understand, you are suggesting to extend DTSTART to accomp=
lish both (although it would be possible to have just one &quot;time range&=
quot; for 2). I am not sure if that would have some impact on current use o=
f DTSTART (
e.g., free-busy queries). The idea of using concepts like &#39;evening&#39;=
 is really interesting, but I am concerned with possible interoperability p=
roblems - that&#39;s why we have opted for &quot;deterministic&quot; forms =
to represent periods of time (&quot;canonical&quot; VFREEBUSY and VAVAILABI=
LITY). I believe that those who have long discussed issues with time repres=
entation on 2445bis can give a definitive opinion on this.
<br><br>Anyway, if we are to use extended VEVENT components to represent im=
precise events, a discussion on the role of DTSTART in this context is fund=
amental.<br><br>Regards,<br><br>F=E1bio.<br><br><div><span class=3D"gmail_q=
uote">
On 6/3/07, <b class=3D"gmail_sendername">Martin Kiff</b> &lt;<a href=3D"mai=
lto:[email-masked]" target=3D"_blank" onclick=3D"return top.js.OpenExtLi=
nk(window,event,this)">

[email-masked]</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" st=
yle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex=
; padding-left: 1ex;">F=E1bio Henrique da Silva wrote:<br><br>&gt; Dear all=
,
<br>
&gt;<br>&gt; This is to announce the new internet-draft:<br>&gt;<br>&gt; &l=
t;<a href=3D"http://www.ietf.org/internet-drafts/draft-silva-events-00.txt"=
 target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,this)"=

http://www.ietf.org/internet-drafts/draft-silva-events-00.txt</a>&gt;<br>
<br><br>Interesting, I&#39;ve read through once and will definitely read th=
rough again.<br>I wonder whether it would go with the flow better to have a=
 &#39;negotiate&#39;<br>block round a set of Vevents? Was this sort of opti=
on considered (and
<br>discarded?)<br><br>BEGIN:ALTERNATES<br><br>BEGIN:VEVENT<br>PREFERENCE:1=
00<br>...<br>END:VEVENT<br><br>BEGIN:VEVENT<br>PREFERENCE:50<br>TRANSP:TRAN=
SPARENT<br>...<br>END:VEVENT<br><br>END:ALTERNATES<br><br>This would give f=
lexibility to have different locations, different
<br>descriptions (and so on) for the different options.<br><br>For imprecis=
e events, I think a lot of the the requirements when<br>publishing (rather =
then negotiating) events would be covered by<br>accepting varying precision=
 in the time:
<br>&nbsp;&nbsp;DTSTART:VALUE=3DHOUR:20070603T090000<br>maybe for something=
 that could start between 9 and 11.<br>&nbsp;&nbsp;DTSTART:VALUE=3DPT2H:200=
70603T090000<br>and, if you know it&#39;s an evening (or whatever) event bu=
t don&#39;t know when...
<br>&nbsp;&nbsp;DTSTART:VALUE=3DEVENING:20070603<br><br>My arguments are ba=
sed on the premises:<br><br>* People don&#39;t necessarily work to second-l=
evel-precision, I don&#39;t think<br>calendaring software should inflict th=
is on them :-)
<br>* Calendaring has to keep a distinction between a &#39;whole day event&=
#39;<br>(like an anniversary) and an &#39;event on a day&#39; (but you don&=
#39;t yet know<br>when) and it would be nice if this could be generalised
<br><br>Regards, Martin<br><br><br></blockquote></div><br>

------=_Part_19062_21242877.1181062819599--