Subject: [Ietf-calsify] Disposition of Various Issues

From: lear at cisco.com (Eliot Lear)
Date: Wed Feb 28 04:42:56 2007

$Chair hat on$

In my opinion, the following issues will close or move to consensus state

Issue 8: P1D or P24H

No consensus to change.  Issue closed.

Issue 54 Version Bump? 

Consensus: no version bump.

Issue 63:  Section 4.8.5.3 Recurrence Date/Times: RDATE <    DTSTART

Based on jabber thus far the consensus is  to accept Bernard's proposed 
clarification.

Issues 68, 69: DST discontinuities

No text has been received.  These issues will be closed without change 
barring objection.

Issue 71: leap-seconds

$chair hat off$

I believe that this issue actually requires no textual change.  As such 
the issue should be closed.

$chair hat on$

There is no proposed text.  Barring objection the issue will be closed.

Issue 72: Section 4.6.5 Timezone component: not required when DTSTART is 
a DATE

Consensus: close the issue no change.

73: 4.8.3.1 Timezone identifier: scope of TZID

Consensus: general agreement but text needed.  Changing state to 
indicate this now.  Without text the issue will be closed in the future.

78: Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM

The recommended change is editorial in nature and corrects non-normative 
text.  My opinion is that this change should proceed.  If you differ, 
now is the time.

Eliot

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Feb 28 05:10:36 2007

> No consensus to change.  Issue closed.

Was it ever proposed to actually remove P1D? I simply wanted a clarification 
what P1D really means. If it always means 24 hours (which I don't think it 
should), that should be explicitly stated, and if it means that you need to 
use date arithmetic (i.e. simply increase the date by one, which I think it 
is supposed to mean), then we need to clarify what happens if the end time 
doesn't exist due to a DST shift.

Currently, some implementations use date arithmetic, some use 24 hours, so 
they'll end up with different end times when a DST shift happens.

I would propose to append three sentences to the description of DURATION in 
section 4.3.6 clarifying this:

"   Description: If the property permits, multiple "duration" values are
   specified by a COMMA character (US-ASCII decimal 44) separated list
   of values. The format is expressed as the [ISO 8601] basic format for
   the duration of time. The format can represent durations in terms of
   weeks, days, hours, minutes, and seconds. A duration of P1D does not
   necessarily mean 24 hours, in particular when a DST shift happens during
   that period it might mean either 23 or 25 hours. If an end time generated
   by a days or weeks duration does not exist due to a shift in daylight
   savings time, a duration of PT24H should be used. If an end time generated
   by such a duration happens twice due to a shift in daylight savings time,
   the first occurrence should be used."

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

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Feb 28 10:18:54 2007

Reinhold,

Thanks much for your email.  Forgive the top post.  I now see at least 
two issues with the text.  The draft refers to ISO 8601:1988 which is 
considered withdrawn.  While we can still reference it we should have 
good reason to do so.  However, if we update to 2004 (the current 
standard) we had better understand the differences and what, if any, 
incompatibilities could arise.

*APPARENTLY* there was some consensus on the issue before I was 
involved, but the messages were unreadable.

Ok, with my chair hat OFF IMHO P1D = one day and does not always equal 
24H.  I see that iCal exhibits this behavior.  My tests for Entourage 
fail due to a combination of factors (including bad patch level on my 
part).  There is perhaps Calconnect data on this one?

Eliot

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFF5X8JTqjEwhXvPN0RAj+iAJ4wCcD/swEQBQ0lyYf5st4niqNbggCeOowG
> oPoiW7k+EMY2vC30pQqhWWA=
> =PG+Q
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Wed Feb 28 13:10:02 2007

> No text has been received.  These issues will be closed without change 

I'm sorry I've not responded on this.

I have a proposal for a "grand unified" solution to DST continuities.
Before I take the time to write up formal text, I'd like to get some feeling
on what people think of this proposal.

I propose that all recurrences be calculated as if in floating time.  Thus,
an event like

DTSTART:20070310T000000
DURATION:PT3H
RRULE:FREQ=DAILY;COUNT=3

would occur take place over the intervals

2007-03-10 00:00:00 - 2007-03-10 03:00:00
2007-03-11 00:00:00 - 2007-03-11 03:00:00
2007-03-12 00:00:00 - 2007-03-12 03:00:00

always, for every time zone.

Thus, with the new U.S. rules, 

DTSTART;TZID=America/New_York:20070310T000000
DURATION:PT3H
RRULE:FREQ=DAILY;COUNT=3

would occur

2007-03-10 00:00:00 EST - 2007-03-10 03:00:00 EST
2007-03-11 00:00:00 EST - 2007-03-11 03:00:00 EDT
2007-03-12 00:00:00 EDT - 2007-03-12 03:00:00 EDT

even though the second recurrence only lasts 2 hours.

If a recurrence's start time occurs more than once, you use the first one;
if an end time occurs twice, you use the last one.  Similarly, if a start
time doesn't exist, you use the first existing time afterward it; if its
end time doesn't exist, you use the last existing time before it.

If both a start time and an end time are in the same non-existent block of
time, the event lasts zero time, but still counts as having occured for the
purpose of COUNT and BYSETPOS.

I think this is probably the best way in general of a) handling all the
corner cases, and b) satisfying the principle of least surprise.

What do people think?  I can probably turn this into actual text without too
much trouble.

-- 
Jonathan Lennox
[email-masked]

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Wed Feb 28 15:43:09 2007

> would occur take place over the intervals

I'm sorry, I don't like that.  PT3H to me means take 3 hours, but above it might be 2-4 hours.  Surely if you really wanted it to finish at 3am you'd say:

DTSTART:20070310T000000
DTEND:20070310T030000
RRULE:FREQ=DAILY;COUNT=3

Nigel

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 2054ec0381699b4fd5541b7dcbd200b9
X-Spam-Score-Summary: 2, 0, 0, 7674dd8417f91f8c, 274b843a5d0108d0, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1539:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2526:2552:2559:2562:2828:3027:3351:3636:3865:3867:3870:3872:3873:3874:4321: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: "Jonathan Lennox" <[email-masked]>
Subject: Re: DST discontinuities (was Re: [Ietf-calsify] Disposition of VariousIssues)
Date: Wed, 28 Feb 2007 23:42:46 -0000
Cc: [email-masked]

> I propose that all recurrences be calculated as if in floating time.  =
Thus,
> an event like
>=20
> DTSTART:20070310T000000
> DURATION:PT3H
> RRULE:FREQ=3DDAILY;COUNT=3D3
>=20
>=20
>=20

I'm sorry, I don't like that.  PT3H to me means take 3 hours, but above =
it might be 2-4 hours.  Surely if you really wanted it to finish at 3am =
you'd say:

DTSTART:20070310T000000
DTEND:20070310T030000
RRULE:FREQ=3DDAILY;COUNT=3D3

Nigel

From: Jonathan Lennox <[email-masked]>
Date: Wed, 28 Feb 2007 16:08:50 -0500
To: "[email-masked]" <[email-masked]>
Subject: DST discontinuities (was Re: [Ietf-calsify] Disposition of Various Issues)

DTSTART:20070310T000000
DURATION:PT3H
RRULE:FREQ=DAILY;COUNT=3

would occur

-- 
Jonathan Lennox
[email-masked]

Date: Wed, 28 Feb 2007 19:17:46 +0100
From: Eliot Lear <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Disposition of Various Issues
Cc: [email-masked]

Reinhold,

Eliot

>    the first occurrence should be used."

Date: Wed, 28 Feb 2007 10:46:17 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] More references to 2446?

Hi,
One of the things that implementers often get wrong is the fact that an 
ORGANIZER of an event is not implicitly considered a participant (ATTENDEE) 
of that event. That behavior is described in section 2.1.3 of 2446 (which 
is actually titled "Acting on Behalf of other Calendar Users" which does 
not really convey the fact that this important statement about roles is 
being made there - something to fix). 2445bis does make passing reference 
to the fact that some roles are defined in 2446, but I would like to see 
some more explicit statements to that effect in actual property definitions.

Proposals:

1) Add the following text somewhere in the description of the ORGANIZER 
property:

The exact behavior and interpretation of the ORGANIZER property and its 
related parameters is defined in iTIP [2446bis]. In particular note that 
the organizer is not implicitly considered a participant in an event or to 
do, and therefore an explicit ATTENDEE property may need to be added for 
the organizer.

2) Same thing for the ATTENDEE property:

The exact behavior and interpretation of the ATTENDEE property and its 
related parameters is defined in iTIP [2446bis]. In particular note that 
the organizer is not implicitly considered a participant in an event or to 
do, and therefore an explicit ATTENDEE property may need to be added for 
the organizer.

I believe these are just editorial changes.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Disposition of Various Issues
Date: Wed, 28 Feb 2007 14:09:28 +0100

Cheers,
Reinhold
- -- 

Date: Wed, 28 Feb 2007 13:41:53 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Disposition of Various Issues

$Chair hat on$

Issue 8: P1D or P24H

Issue 54 Version Bump? 

Issue 71: leap-seconds

$chair hat off$

$chair hat on$

Eliot

Date: Mon, 26 Feb 2007 15:55:20 -0600
From: Clint Talbert <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: Issue 72: Re: [Ietf-calsify] issue status for 2445bis
Cc: "[email-masked]" <[email-masked]>

Replies inline...
Bernard Desruisseaux wrote:
>
> Clint,
>
> Before I brought issue 72 to the mailing list I checked RFC 2445 to find
> out whether the TZID parameter could be specified on a property of DATE
> value type or not. On the basis that something not forbidden is allowed,
> it would be allowed.
>
This was also the way I always understood it.
> In section 4.2.19 Time Zone Identifier of RFC 2445 it only says:
>
>  > Description: The parameter MUST be specified on the "DTSTART",
>  > "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
>  > TIME or TIME value type is specified and when the value is not either
>  > a UTC or a "floating" time.
>
> It clearly brings one to believe that the TZID parameter was meant to
> be used with properties of DATE-TIME and TIME value type.
>
> We should probably clarify whether the TZID parameter should be allowed
> on properties of DATE value type or not.
>
In my opinion, more clarity rarely hurts.  You could easily make this 
more clear by stating "DATE-TIME, DATE, or TIME" in the list above. 
> On one hand, if one really cares about the time zone, why isn't one
> specifying a DATE-TIME value instead. On the other hand, specifying
> VALUE=DATE is the only interoperable way to differentiate an "all
> day event" from a regular event and thus give a hint to the client
> application on how to display the event to the end user.
>
I think you've hit the nail on the head as to why this issue is 
difficult.  By all means, you *should* use times if you're sharing one 
of these events across a timezone, but most users would never think 
about that when creating an all-day event.  I haven't come up with a 
seamless way to enforce this convention yet.
> For what is worth, the following Google search reported 53 hits:
>
> http://www.google.com/search?q=%22+DTSTART%3BVALUE%3DDATE%3BTZID%3D%22
>
> Would you like to propose a text change?
>
I'll leave that decision to you and Eliot.  I have the text up above, 
which is a pretty minor change.  However, it sounds like this issue was 
already addressed, and if that is the case, I don't have any desire to 
re-open it over my own misunderstanding.

Thanks,
Clint

Date: Mon, 26 Feb 2007 14:45:57 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Clint Talbert <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Issue 72: Re: [Ietf-calsify] issue status for 2445bis
Cc: "[email-masked]" <[email-masked]>

Eliot,

Issue 72 is not up to date in the tracker.  Please see:

http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001486.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001487.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001488.html

I believe consensus was reached, but it's clearly your call!

Clint,

Before I brought issue 72 to the mailing list I checked RFC 2445 to find
out whether the TZID parameter could be specified on a property of DATE
value type or not. On the basis that something not forbidden is allowed,
it would be allowed.

In section 4.2.19 Time Zone Identifier of RFC 2445 it only says:

  > Description: The parameter MUST be specified on the "DTSTART",
  > "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
  > TIME or TIME value type is specified and when the value is not either
  > a UTC or a "floating" time.

It clearly brings one to believe that the TZID parameter was meant to
be used with properties of DATE-TIME and TIME value type.

We should probably clarify whether the TZID parameter should be allowed
on properties of DATE value type or not.

On one hand, if one really cares about the time zone, why isn't one
specifying a DATE-TIME value instead. On the other hand, specifying
VALUE=DATE is the only interoperable way to differentiate an "all
day event" from a regular event and thus give a hint to the client
application on how to display the event to the end user.

For what is worth, the following Google search reported 53 hits:

http://www.google.com/search?q=%22+DTSTART%3BVALUE%3DDATE%3BTZID%3D%22

Would you like to propose a text change?

Cheers,
Bernard

Clint Talbert wrote:
> Eliot Lear wrote:
>> Clint Talbert wrote:
>>> Hello all,
>>>
>>> I'm a bit confused by Section 4.6.5 Time Zone Component: Not required 
>>> when DTSTART is a DATE 
>>> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72>.  
>>> Perhaps I missed something, but why would you NOT require a Timezone 
>>> definition when DTSTART is a date?
>>
>> Consider the case of a holiday - particularly one that is observed in 
>> many locations.  When does it start, precisely?
> Ah, yes, I see.  I thought there would be a good reason. :-)
> 
> On re-reading the text again, I now see that you are merely saying that 
> a DATE type of DTSTART does not *require* a VTIMEZONE reference.
> You are *not* saying that a DATE type of DTSTART should NEVER have a 
> VTIMEZONE reference (which is how I read it this morning before my 
> coffee kicked in).
> 
> I apologize for the inconvenience and misunderstanding.
> 
> Clint

Date: Mon, 26 Feb 2007 13:44:39 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Wrong ABNF?
Cc: [email-masked]

Cyrus,

Good catch!  My mistake.  Will be fixed in -06.

Thanks,
Bernard

Cyrus Daboo wrote:
> Hi,
> In 2445bis we have:
> 
>      QSAFE-CHAR    = WSP / %x21 / %x23-7E / NON-US-ASCII
>      ; Any character except CONTROL, DQUOTE, ";", ":", ","
> 
> but in 2445 we had:
> 
>     QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
>     ; Any character except CTLs and DQUOTE
> 
> Looks to me like the comment in 2445bis is wrong - it certainly does not 
> agree with the character range specified by the ABNF.
> 
> Proposal: change the comment to the one in 2445.
> 
> BTW It still bothers me that you can't have a double-quote character in 
> a parameter value, but I guess we have to live with that.
> 

Date: Mon, 26 Feb 2007 10:29:42 -0600
From: Clint Talbert <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] issue status for 2445bis

Eliot Lear wrote:
> Clint Talbert wrote:
>> Hello all,
>>
>> I'm a bit confused by Section 4.6.5 Time Zone Component: Not required 
>> when DTSTART is a DATE 
>> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72>.  
>> Perhaps I missed something, but why would you NOT require a Timezone 
>> definition when DTSTART is a date?
>
> Consider the case of a holiday - particularly one that is observed in 
> many locations.  When does it start, precisely?
Ah, yes, I see.  I thought there would be a good reason. :-)

 On re-reading the text again, I now see that you are merely saying that 
a DATE type of DTSTART does not *require* a VTIMEZONE reference. 

You are *not* saying that a DATE type of DTSTART should NEVER have a 
VTIMEZONE reference (which is how I read it this morning before my 
coffee kicked in).

I apologize for the inconvenience and misunderstanding.

Clint

Date: Mon, 26 Feb 2007 16:54:46 +0100
From: Eliot Lear <[email-masked]>
To: Clint Talbert <[email-masked]>
Subject: Re: [Ietf-calsify] issue status for 2445bis
Cc: "[email-masked]" <[email-masked]>

Clint Talbert wrote:
> Hello all,
>
> I'm a bit confused by Section 4.6.5 Time Zone Component: Not required 
> when DTSTART is a DATE 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72>.  
> Perhaps I missed something, but why would you NOT require a Timezone 
> definition when DTSTART is a date?

Consider the case of a holiday - particularly one that is observed in 
many locations.  When does it start, precisely?

Eliot

To: Calsify WG <[email-masked]>
From: Jay Batson <[email-masked]>
Date: Mon, 26 Feb 2007 08:22:17 -0500
Subject: [Ietf-calsify] Issues with Security / Spoofing section

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

Re-sending the message below, because I believe it still to be an  
issue, and there was no response from the list regarding my point.

Since Eliot seems to be collecting the "definitive list," and this  
wasn't on it, I hope this will make it onto the radar screen.
-jb

------------- Original message ---------------

I was reviewing the latest draft, and finally (after not paying  
sufficient attention previously) noted that the Security section has  
a real problem.

The SPOOFING section is trouble waiting to happen.  Currently, that  
section says:

"... the "Organizer" is the only person authorized to make changes to  
an existing "VEVENT", "VTODO", "VJOURNAL" calendar component...."

(I'm going to restrict my comments to the application of that logic  
to VTODO and VJOURNAL components, because I think VEVENT may have  
different needs.)

ASSERTION:
In general, the current language isn't practical in real life.  When  
VTODOs (and/or VJOURNALs) are used in group task coordination  
applications, it is highly likely that other persons besides the  
"Organizer" will need to be able to modify these components after  
they are created.  Thus, the current restriction is not practical and  
should not remain.

ILLUSTRATIVE BACKGROUND:
Assume:
- a collaborative application that stores tasks assigned to people in  
a project team;
- tasks are stored as VTODO entries in a project.ics file (and the  
entries are replicated to team members through some mechanism);
- all users in a project have access to all the project information  
(e.g. all have read-rights to the .ics file)
- assume the software implements the current SPOOFING constraint --  
that only the "Organizer" (task assignor) can modify the task details.

Real-life user behaviors will dictate that users want (at least) the  
"Attendees" to be able to modify the VTODO entry.  People often need  
to modify task descriptions to conform with changed requirements,  
add / modify / change assignees, change dates when all agree on the  
need for change (but the original assignor isn't present to make the  
change), etc.

Note:  Our task management software uses iCal for tasks, and most of  
our customers want *ANY* person in the project team to be able to  
modify the task details for *ANY* task in the project -- not only the  
"Attendees" of a project.  For instance, if Sally assigned task A to  
herself, but went to the hospital to have a baby this morning, and  
Jim is going to assume responsibility for it, Jim must have the  
ability to change the "Attendee" - and probably the due-date, too.

In real life, teams work together; it's not a strict hierarchy of  
assignor/assignee, and task details change constantly.  Therefore,  
the current SPOOFING restriction is simply not practical if iCalendar  
VTODOs are to be used in anything else than a single-user software  
application.

PROPOSAL:
2445 should simply be silent about who can, or cannot modify (at  
least) VTODO and VJOURNAL components.  Access control is outside the  
scope of the definition of task data.  If some application wants to  
decide to only grant write capabilities to the Organizer it can.  If  
another application wants to maintain ACLs outside the scope of the  
calendar object, it can.  If others want to add x-props to include  
ACL guidance (which could be difficult to enforce if there is no  
secure transit), it can.  It's not the role of 2445 to specify ACLs;  
it is only its role to define the listed components in *this* case  
(of tasks/journals).

I propose the SPOOFING section be rewritten to indicate that the RFC  
is providing no access control for these two components, identify the  
risks of uncontrolled access, and leave security implementation up to  
some externality, e.g. iTIP.  Here is some proposed text (though I  
suspect this needs LOTS of discussion before it goes in):

NEW LANGUAGE:
-----------
SPOOFING:
In this memo, there is no restriction on who is authorized to make  
changes to a "VTODO" or "VJOURNAL" calendar component entry.  Some  
applications using these components in a collaborative setting may  
intentionally desire to provide "Attendees" the ability to update  
this data based on ongoing actual activities, and communicate these  
changes to the "Attendees" as part of the collaborative process.   
Malicious behavior in this context can of course result in data  
changes or loss that is unexpected by the "Attendees".  This is an  
inherent risk in any situation where all "Attendees" are  
collaborating on "VTODO" or "VJOURNAL" entries, and it is up to the  
individuals, or to some other controlling technology, such as iTIP,  
document versioning, or other, to provide any desired control over  
the ability of "Attendees" to make changes in these components.
-----------

Note again that I cannot speak to the implications of changing the  
SPOOFING section relative to VEVENT components.  There must of course  
be SOME description of how to handle VEVENT components.  My language  
proposal above does NOT address this.  Somebody more versed in the  
implications of calendaring must come up with it.

Comments?
-jb

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

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

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>Re-sending the message =
below, because I believe it still to be an issue, and there was no =
response from the list regarding my point.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Since Eliot seems to be =
collecting the "definitive list," and this wasn't on it, I hope this =
will make it onto the radar screen.</DIV><DIV>-jb</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>------------- Original =
message ---------------</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I was reviewing the latest =
draft, and finally (after not paying sufficient attention previously) =
noted that the Security section has a real problem.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The SPOOFING section is =
trouble waiting to happen.=A0 Currently, that section =
says:</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>"... =
the "Organizer" is the only person authorized to make changes to an =
existing "VEVENT", "VTODO", "VJOURNAL" calendar =
component...."</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>(I'm going to restrict my =
comments to the application of that logic to VTODO and VJOURNAL =
components, because I think VEVENT may have different =
needs.)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>ASSERTION:</DIV><DIV>In =
general, the current language isn't practical in real life.=A0 =
When=A0VTODOs (and/or VJOURNALs) are used in group task coordination =
applications, it is highly likely that other persons besides the =
"Organizer" will need to be able to modify these components after they =
are created.=A0 Thus, the current restriction is not practical and =
should not remain.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>ILLUSTRATIVE =
BACKGROUND:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Assume:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">-=A0a collaborative application that stores tasks =
assigned to people in a project team;</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">- tasks =
are stored as VTODO entries in a project.ics file (and the entries are =
replicated to team members through some mechanism);</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- all users in a project have access to all the =
project information (e.g. all have read-rights to the .ics =
file)</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">- assume the software implements =
the current SPOOFING constraint -- that only the "Organizer" (task =
assignor) can modify the task details.</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Real-life =
user behaviors will dictate that users want (at least) the "Attendees" =
to be able to modify the VTODO entry.=A0 People often need to modify =
task descriptions to conform with changed requirements, add / modify / =
change assignees, change dates when all agree on the need for change =
(but the original assignor isn't present to make the change), =
etc.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Note:=A0 Our =
task management software uses iCal for tasks, and most of our customers =
want=A0*ANY* person in the project team to be able to modify the task =
details for *ANY* task in the project -- not only the "Attendees" of a =
project.=A0 For instance, if Sally assigned task A to herself, but went =
to the hospital to have a baby this morning, and Jim is going to assume =
responsibility for it, Jim must have the ability to change the =
"Attendee" - and probably the due-date, too.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><BR class=3D"khtml-block-placeholder"></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">In real life, teams work together; it's not a strict =
hierarchy of assignor/assignee, and task details change constantly.=A0 =
Therefore, the current SPOOFING restriction is simply not practical if =
iCalendar VTODOs are to be used in anything else than a single-user =
software application.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">PROPOSAL:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">2445 should simply be silent =
about who can, or cannot modify (at least) VTODO and VJOURNAL =
components.=A0 Access control is outside the scope of the definition of =
task data.=A0 If some application wants to decide to only grant write =
capabilities to the Organizer it can.=A0 If another application wants to =
maintain ACLs outside the scope of the calendar object, it can.=A0 If =
others want to add x-props to include ACL guidance (which could be =
difficult to enforce if there is no secure transit), it can.=A0 It's not =
the role of 2445 to specify ACLs; it is only its role to define the =
listed components in *this* case (of tasks/journals).</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><BR class=3D"khtml-block-placeholder"></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I propose the SPOOFING section be rewritten to =
indicate that the RFC is providing no access control for these two =
components, identify the risks of uncontrolled access, and leave =
security implementation up to some externality, e.g. iTIP.=A0 Here is =
some proposed text (though I suspect this needs LOTS of discussion =
before it goes in):</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">NEW =
LANGUAGE:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">-----------</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">SPOOFING:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">In this memo, =
there is no restriction on who is authorized to make changes to a =
"VTODO" or "VJOURNAL" calendar component entry.=A0 Some applications =
using these components in a collaborative setting may intentionally =
desire to provide "Attendees" the ability to update this data based on =
ongoing actual activities, and communicate these changes to the =
"Attendees" as part of the collaborative process.=A0 Malicious behavior =
in this context can of course result in data changes or loss that is =
unexpected by the "Attendees".=A0 This is an inherent risk in any =
situation where all "Attendees" are collaborating on "VTODO" or =
"VJOURNAL" entries, and it is up to the individuals, or to some other =
controlling technology, such as iTIP, document versioning, or other, to =
provide any desired control over the ability of "Attendees" to make =
changes in these components.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">-----------</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Note again =
that I cannot speak to the implications of changing the SPOOFING section =
relative to VEVENT components.=A0 There must of course be SOME =
description of how to handle VEVENT components.=A0 My language proposal =
above does NOT address this.=A0 Somebody more versed in the implications =
of calendaring must come up with it.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Comments?</DIV><DIV>-jb</DIV>=
<BR><DIV> <SPAN class=3D"Apple-style-span" style=3D"border-collapse: =
separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: =
0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; =
"><DIV>-------------</DIV><DIV>Jay Batson</DIV><DIV><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV=
><DIV>+1-978-824-0111 (w)</DIV><DIV>+1-978-758-1599 (m)</DIV><BR =
class=3D"Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>=

--Apple-Mail-24-915409424--

Date: Mon, 26 Feb 2007 07:13:44 -0600
From: Clint Talbert <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] issue status for 2445bis
Cc: "[email-masked]" <[email-masked]>

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

Hello all,

I'm a bit confused by Section 4.6.5 Time Zone Component: Not required 
when DTSTART is a DATE 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72>.  
Perhaps I missed something, but why would you NOT require a Timezone 
definition when DTSTART is a date?  Here's an example.

I am based in America/Chicago timezone
I am reading an ICS containing an all day event on Monday, Feb. 26 from 
Australia/Sydney

I would expect my application to display that event as occurring on 
Sunday, Feb 25 in the Chicago timezone (because this is when midnight, 
Monday Feb 26 occurs in Sydney).   Since 17 hours of Sydney's Monday are 
shared by Chicago's Sunday, it seems natural to display this event as 
occurring on Sunday in the Chicago time.  (In contrast, only seven hours 
of Sydney's Monday coincide with Chicago's Monday)  So it seems that the 
right thing to do would be to display this event on Sunday when viewed 
in the Chicago timezone.

I guess the point I'm trying to make is that a DTSTART without timezone 
information will only be correct in timezones that are near the same 
offset as the originating timezone of the event. 

I'm sure there are good arguments for this change, but I can't 
find/don't remember them.  Please remind me of why you decided that 
timezones are not required when DTSTART is a DATE.

Thanks,

Clint

Eliot Lear wrote:
> Dear all,
>
> Below is a table best viewed in HTML of issues from the tracker 
> relating to RFC2445bis.  The chairs would remind you that the issues 
> list is closed for all but issues relating to new problems caused by 
> the agreed changes, and we will scrutinize any request for such new 
> issues intensely.  Issues for which there is no text will be closed in 
> the next two weeks.  Some of the issues below are close to being 
> resolved.  Issue 54 is probably resolved with no change, for 
> instance.  Issue 8 may have been handled by another issue.  You can 
> review all issues by going to 
> http://www.ofcourseimright.com/cgi-bin/roundup/calsify.  Search is on 
> the left.  No need for an account, but feel free to register if you like.
>
> Regards,
>
> Eliot
>
>
> ID 	Activity 	Title 	Status
> rfc2445bis
> 10 	3 days ago 	Reinhold Kainhofer: end date not inclusive 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10> 	notext
> 11 	4 months ago 	Reinhold Kainhofer: additional examples, VTIMEZONEs, 
> RRULEs 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11> 	notext
> 23 	2 weeks ago 	Contradiction between UNTIL BNF rule and text 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue23> 	Discuss
> 54 	4 months ago 	Version value bump? 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue54> 	unread
> 63 	2 weeks ago 	Section 4.8.5.3 Recurrence Date/Times: RDATE < 
> DTSTART 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue63> 	Discuss
> 67 	2 weeks ago 	Section 4.8.2.5 Duration: VFREEBUSY request 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue67> 	Discuss
> 68 	2 weeks ago 	DST discontinuities part 1: date-times that fall in 
> discontinutities 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue68> 	notext
> 69 	2 weeks ago 	DST discontinuities part 2: discontinuities for 
> recurring event start times 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue69> 	notext
> 70 	2 weeks ago 	DST discontinuities part 3: discontinuities for event 
> end times 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue70> 	Discuss
> 71 	2 weeks ago 	The "other" time discontinuity: leap-seconds 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue71> 	Discuss
> 72 	2 weeks ago 	Section 4.6.5 Time Zone Component: Not required when 
> DTSTART is a DATE 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72> 	Discuss
> 73 	2 weeks ago 	Section 4.8.3.1 Time Zone Identifier: Scope of TZID] 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue73> 	Discuss
> 78 	4 days ago 	Section 4.6.5 Time Zone Component: DTSTART with 
> TZOFFSETFROM 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue78> 	Discuss
> 79 	4 days ago 	Section 4.6.5 Time Zone Component: DTSTART always an 
> onset date-time of an observance? 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue79> 	Discuss
> 8 	4 months ago 	Reinhold Kainhofer: Deprecate P1D or P24H? 
> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue8> 	notext
>
>
> ------------------------------------------------------------------------
>

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello all,<br>
<br>
I'm a bit confused by <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72">Section
4.6.5 Time Zone Component: Not required when DTSTART is a DATE</a>. 
Perhaps I missed something, but why would you NOT require a Timezone
definition when DTSTART is a date?  Here's an example.<br>
<br>
I am based in America/Chicago timezone<br>
I am reading an ICS containing an all day event on Monday, Feb. 26 from
Australia/Sydney<br>
<br>
I would expect my application to display that event as occurring on
Sunday, Feb 25 in the Chicago timezone (because this is when midnight,
Monday Feb 26 occurs in Sydney).   Since 17 hours of Sydney's Monday
are shared by Chicago's Sunday, it seems natural to display this event
as occurring on Sunday in the Chicago time.  (In contrast, only seven
hours of Sydney's Monday coincide with Chicago's Monday)  So it seems
that the right thing to do would be to display this event on Sunday
when viewed in the Chicago timezone.<br>
<br>
I guess the point I'm trying to make is that a DTSTART without timezone
information will only be correct in timezones that are near the same
offset as the originating timezone of the event.  <br>
<br>
I'm sure there are good arguments for this change, but I can't
find/don't remember them.  Please remind me of why you decided that
timezones are not required when DTSTART is a DATE.<br>
<br>
Thanks,<br>
<br>
Clint<br>
<br>
Eliot Lear wrote:
<blockquote cite="mid:[email-masked]" type="cite">Dear all,<br>
  <br>
Below is a table best viewed in HTML of issues from the tracker
relating to RFC2445bis.  The chairs would remind you that the issues
list is closed for all but issues relating to new problems caused by
the agreed changes, and we will scrutinize any request for such new
issues intensely.  Issues for which there is no text will be closed in
the next two weeks.  Some of the issues below are close to being
resolved.  Issue 54 is probably resolved with no change, for instance. 
Issue 8 may have been handled by another issue.  You can review all
issues by going to
  <a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify">http://www.ofcourseimright.com/cgi-bin/roundup/calsify</a>. 
Search is on
the left.  No need for an account, but feel free to register if you
like.<br>
  <br>
Regards,<br>
  <br>
Eliot<br>
  <br>
  <br>
  <table class="list">
    <tbody>
      <tr>
        <th>ID</th>
        <th>Activity</th>
        <th>Title</th>
        <th>Status</th>
      </tr>
      <tr>
        <th class="group" colspan="4">rfc2445bis</th>
      </tr>
      <tr>
        <td>10</td>
        <td class="date">3 days ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10">Reinhold
Kainhofer: end date not inclusive</a> </td>
        <td>notext</td>
      </tr>
      <tr>
        <td>11</td>
        <td class="date">4 months ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11">Reinhold
Kainhofer: additional examples, VTIMEZONEs, RRULEs</a> </td>
        <td>notext</td>
      </tr>
      <tr>
        <td>23</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue23">Contradiction
between UNTIL BNF rule and text</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>54</td>
        <td class="date">4 months ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue54">Version
value bump?</a> </td>
        <td>unread</td>
      </tr>
      <tr>
        <td>63</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue63">Section
4.8.5.3 Recurrence Date/Times: RDATE &lt; DTSTART</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>67</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue67">Section
4.8.2.5 Duration: VFREEBUSY request</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>68</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue68">DST
discontinuities part 1: date-times that fall in discontinutities</a> </td>
        <td>notext</td>
      </tr>
      <tr>
        <td>69</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue69">DST
discontinuities part 2: discontinuities for recurring event start times</a>
        </td>
        <td>notext</td>
      </tr>
      <tr>
        <td>70</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue70">DST
discontinuities part 3: discontinuities for event end times</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>71</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue71">The
"other" time discontinuity: leap-seconds</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>72</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72">Section
4.6.5 Time Zone Component: Not required when DTSTART is a DATE</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>73</td>
        <td class="date">2 weeks ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue73">Section
4.8.3.1 Time Zone Identifier: Scope of TZID]</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>78</td>
        <td class="date">4 days ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue78">Section
4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>79</td>
        <td class="date">4 days ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue79">Section
4.6.5 Time Zone Component: DTSTART always an onset date-time of an
observance?</a> </td>
        <td>Discuss</td>
      </tr>
      <tr>
        <td>8</td>
        <td class="date">4 months ago</td>
        <td> <a moz-do-not-send="true"
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue8">Reinhold
Kainhofer: Deprecate P1D or P24H?</a> </td>
        <td>notext</td>
      </tr>
    </tbody>
  </table>
  <br>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Ietf-calsify mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------080208030806070804020209--

Date: Mon, 26 Feb 2007 11:36:49 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] issue status for 2445bis

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

Dear all,

Below is a table best viewed in HTML of issues from the tracker relating 
to RFC2445bis.  The chairs would remind you that the issues list is 
closed for all but issues relating to new problems caused by the agreed 
changes, and we will scrutinize any request for such new issues 
intensely.  Issues for which there is no text will be closed in the next 
two weeks.  Some of the issues below are close to being resolved.  Issue 
54 is probably resolved with no change, for instance.  Issue 8 may have 
been handled by another issue.  You can review all issues by going to 
http://www.ofcourseimright.com/cgi-bin/roundup/calsify.  Search is on 
the left.  No need for an account, but feel free to register if you like.

Regards,

Eliot

ID 	Activity 	Title 	Status
rfc2445bis
10 	3 days ago 	Reinhold Kainhofer: end date not inclusive 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10> 	notext
11 	4 months ago 	Reinhold Kainhofer: additional examples, VTIMEZONEs, 
RRULEs 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11> 	notext
23 	2 weeks ago 	Contradiction between UNTIL BNF rule and text 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue23> 	Discuss
54 	4 months ago 	Version value bump? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue54> 	unread
63 	2 weeks ago 	Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue63> 	Discuss
67 	2 weeks ago 	Section 4.8.2.5 Duration: VFREEBUSY request 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue67> 	Discuss
68 	2 weeks ago 	DST discontinuities part 1: date-times that fall in 
discontinutities 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue68> 	notext
69 	2 weeks ago 	DST discontinuities part 2: discontinuities for 
recurring event start times 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue69> 	notext
70 	2 weeks ago 	DST discontinuities part 3: discontinuities for event 
end times 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue70> 	Discuss
71 	2 weeks ago 	The "other" time discontinuity: leap-seconds 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue71> 	Discuss
72 	2 weeks ago 	Section 4.6.5 Time Zone Component: Not required when 
DTSTART is a DATE 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72> 	Discuss
73 	2 weeks ago 	Section 4.8.3.1 Time Zone Identifier: Scope of TZID] 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue73> 	Discuss
78 	4 days ago 	Section 4.6.5 Time Zone Component: DTSTART with 
TZOFFSETFROM 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue78> 	Discuss
79 	4 days ago 	Section 4.6.5 Time Zone Component: DTSTART always an 
onset date-time of an observance? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue79> 	Discuss
8 	4 months ago 	Reinhold Kainhofer: Deprecate P1D or P24H? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue8> 	notext

--------------020709020603080908070103
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>
Below is a table best viewed in HTML of issues from the tracker
relating to RFC2445bis.  The chairs would remind you that the issues
list is closed for all but issues relating to new problems caused by
the agreed changes, and we will scrutinize any request for such new
issues intensely.  Issues for which there is no text will be closed in
the next two weeks.  Some of the issues below are close to being
resolved.  Issue 54 is probably resolved with no change, for instance. 
Issue 8 may have been handled by another issue.  You can review all
issues by going to
<a class="moz-txt-link-freetext" href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify">http://www.ofcourseimright.com/cgi-bin/roundup/calsify</a>.  Search is on
the left.  No need for an account, but feel free to register if you
like.<br>
<br>
Regards,<br>
<br>
Eliot<br>
<br>
<br>
<table class="list">
  <tbody>
    <tr>
      <th>ID</th>
      <th>Activity</th>
      <th>Title</th>
      <th>Status</th>
    </tr>
    <tr>
      <th class="group" colspan="4">rfc2445bis</th>
    </tr>
    <tr>
      <td>10</td>
      <td class="date">3 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10">Reinhold
Kainhofer: end date not inclusive</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>11</td>
      <td class="date">4 months ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11">Reinhold
Kainhofer: additional examples, VTIMEZONEs, RRULEs</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>23</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue23">Contradiction
between UNTIL BNF rule and text</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>54</td>
      <td class="date">4 months ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue54">Version
value bump?</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>63</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue63">Section
4.8.5.3 Recurrence Date/Times: RDATE &lt; DTSTART</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>67</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue67">Section
4.8.2.5 Duration: VFREEBUSY request</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>68</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue68">DST
discontinuities part 1: date-times that fall in discontinutities</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>69</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue69">DST
discontinuities part 2: discontinuities for recurring event start times</a>
      </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>70</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue70">DST
discontinuities part 3: discontinuities for event end times</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>71</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue71">The
"other" time discontinuity: leap-seconds</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>72</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72">Section
4.6.5 Time Zone Component: Not required when DTSTART is a DATE</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>73</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue73">Section
4.8.3.1 Time Zone Identifier: Scope of TZID]</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>78</td>
      <td class="date">4 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue78">Section
4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>79</td>
      <td class="date">4 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue79">Section
4.6.5 Time Zone Component: DTSTART always an onset date-time of an
observance?</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>8</td>
      <td class="date">4 months ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue8">Reinhold
Kainhofer: Deprecate P1D or P24H?</a> </td>
      <td>notext</td>
    </tr>
  </tbody>
</table>
<br>
</body>
</html>

--------------020709020603080908070103--

Date: Sun, 25 Feb 2007 20:02:39 +0100
From: Eliot Lear <[email-masked]>
To: Martin Kiff <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax	for	the	UIDproperty
Cc: [email-masked]

Martin,

What's the threat?  A domain name is not enough to be a threat.  Those 
are easily located, one way or another.  If you really want to be scared 
about this, we will need to find a way to obscure participant addresses.

Eliot

Date: Sat, 24 Feb 2007 17:23:49 +0100
From: Martin Kiff <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax	for	the	UIDproperty
Cc: [email-masked]

Eliot Lear wrote:

> In fact, can someone say to me why a change here isn't gratuitous?  
> Does anyone actually suffer with the existing text?
>
> Eliot

For me, a change away from an 'obvious' email style address is not 
gratuitous. The original spec was written in more innocent times and as 
it stands it is _recommending_ something that is bad practice.

I suspect a minimal change would be OK based on the assumption that you 
are defending against naive address harvesters, ones which might not  be 
distinguishing between .html and .ics

I worry about suggesting alternatives; one which you might use 
internally and one externally, I thought the idea of the UID was that it 
uniquely identified the event so that the event had a one UID (and 
conversely however a calendar agent met it, if it had the same UID then 
it was talking about the same event).

Regards, Martin

Date: Sat, 24 Feb 2007 10:58:46 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Wrong ABNF?

Hi,
In 2445bis we have:

      QSAFE-CHAR    = WSP / %x21 / %x23-7E / NON-US-ASCII
      ; Any character except CONTROL, DQUOTE, ";", ":", ","

but in 2445 we had:

     QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
     ; Any character except CTLs and DQUOTE

Looks to me like the comment in 2445bis is wrong - it certainly does not 
agree with the character range specified by the ABNF.

Proposal: change the comment to the one in 2445.

BTW It still bothers me that you can't have a double-quote character in a 
parameter value, but I guess we have to live with that.

-- 
Cyrus Daboo

To: Bernard Desruisseaux <[email-masked]>
Subject: Re: Handling of DUE; VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day	Events and DTEND]
Date: Fri, 23 Feb 2007 12:21:12 -0500
From: "Bruce Kahn" <[email-masked]>
Cc: [email-masked]

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

[email-masked] wrote on 02/19/2007 11:39:23 AM:
> The same way that the DTEND property specifies the non-inclusive end
> of events, the DUE property should be handled the same way for to-dos.

+1

> The implication here is that any application that presents a DUE=20
property
> of DATE value type as a "Due date" needs to substract one day to its=20
value
> since for an end user if some to-do is due on Feburary 14, 2007 he has
> until the end of the day to complete the to-do (i.e., until 23:59:59 on
> February 14, 2007). I've been told that some applications are presenting
> this value as "Due by" to avoid this ambiguity.

  There are be different ways to express the same intent.  If something=20
has a due date of today then it I have until the end of the day to get it=20
done.  The same situation can also be described by saying that whatever it =

is must be done by midnight tomorrow.  Users do not care how you write it=20
as long as you can clearly and consistently express the correct intent. We =

need to clearly define the meaning in iCalendar so that UI's are free to=20
express it accurately but in their own way to the user.

  I find that a "due by" meaning is much less ambiguous then a "due date"=20
one but perhaps that's just me.

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                                INet:=20
Bruce=[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Once you make something idiot-proof, they build a better idiot.

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

<br><tt><font size=3D2>[email-masked] wrote on 02/1=
9/2007
11:39:23 AM:<br>&gt; The same way that the DTEND property specifies the non=
-inclusive end<br>&gt; of events, the DUE property should be handled the sa=
me way for to-dos.<br></font></tt><br><tt><font size=3D2>+1</font></tt><br>=
<br><tt><font size=3D2>&gt; The implication here is that any application
that presents a DUE property<br>&gt; of DATE value type as a &quot;Due date=
&quot; needs to substract one
day to its value<br>&gt; since for an end user if some to-do is due on Febu=
rary 14, 2007 he
has<br>&gt; until the end of the day to complete the to-do (i.e., until 23:=
59:59
on<br>&gt; February 14, 2007). I've been told that some applications are pr=
esenting<br>&gt; this value as &quot;Due by&quot; to avoid this ambiguity.<=
br></font></tt><br><font size=3D2 face=3D"sans-serif">&nbsp; There are be d=
ifferent ways to
express the same intent. &nbsp;If something has a due date of today then
it I have until the end of the day to get it done. &nbsp;The same situation
can also be described by saying that whatever it is must be done by midnight
tomorrow. &nbsp;Users do not care how you write it as long as you can clear=
ly
and consistently express the correct intent. &nbsp;We need to clearly define
the meaning in iCalendar so that UI's are free to express it accurately
but in their own way to the user.</font><br><br><font size=3D2 face=3D"sans=
-serif">&nbsp; I find that a &quot;due by&quot;
meaning is much less ambiguous then a &quot;due date&quot; one but perhaps
that's just me.</font><br><br><font size=3D2 face=3D"sans-serif">Bruce</fon=
t><br><font size=3D2 face=3D"sans-serif">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Bruce Kahn &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce=5FKahn@notesdev=
.ibm.com<br>Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>IBM Software Group &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>Once you mak=
e something idiot-proof, they build a better idiot.</font><br><BR>
--=_alternative 005F28B48525728B_=--

From: Matthew Willis <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property
Date: Fri, 23 Feb 2007 12:08:00 -0500
To: [email-masked]

On Feb 22, 2007, at 10:39 AM, Martin Kiff wrote:

> If you put an .ics file on the web, you've published a lot of email- 
> like addresses; be prepared for them to be picked up by Spam- 
> harvesters. I think the spec should suggest some other format.

One could reverse the order.  ex: com.mozilla@lilmatt-GUID

We use GUIDs currently in Sunbird and Lightning, and I believe  
iCal.app uses them as well.  We should include that as an alternative  
format.

FWIW: We have had trouble dealing with the long GUIDs iCal.app uses,  
and folding them properly.

-lilmatt

Date: Fri, 23 Feb 2007 16:16:40 +0100
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for	the	UIDproperty
Cc: [email-masked]

In fact, can someone say to me why a change here isn't gratuitous?  Does 
anyone actually suffer with the existing text?

Eliot

Cyrus Daboo wrote:
> Hi Tim,
>
> --On February 23, 2007 7:38:37 AM -0500 Tim Hare <[email-masked]> 
> wrote:
>
>> Here's a proposal for UID, although after I wrote it I'm not sure how
>> effective it would be against spam (it was written in a short time
>> period). Something along these lines could work, though; perhaps 
>> changing
>> it to (uniqueID)-hostname-domain where the '@' is removed?
>>
>>
>>
>>
>> Proposed Text for the UID property:
>>
>>  Description:  The "UID" itself MUST be a globally unique identifier.
>>       The generator of the identifier MUST guarantee that the identifier
>>       is unique.  There are several algorithms that can be used to
>>       accomplish this.  The identifier is RECOMMENDED to be the
>>       identical syntax to the [RFC2822] addr-spec, however to avoid
>> issues        with unsolicited e-mail ("spam"), a false hostname SHOULD
>> be used.  A good
>>       method to assure uniqueness and security is to put a 
>> combination of
>> the
>>       current calendar date and time of day (i.e., formatted as in a
>> DATE-TIME
>>       value) along with some currently unique (perhaps sequential)
>> identifier
>>       available on the system (for example a procss id number) on
>> left-hand side
>>       of the "@", and on the right hand side put a non-existent hostname
>> followed
>>       by the domain name or a domain literal IP address of the host on
>> which the
>>       identifier was created.   Using a date/time value on the left hand
>> side and
>>       a domain name or domain literal on the right hand side makes it
>> possible to
>>       guarantee uniqueness since no two hosts should be using the same
>> domain name
>>       or IP address at the same time. Using the non-existent hostname on
>> the
>>
>>       right-hand side allows the generator of the message identifier to
>> avoid
>>       unsolicited e-mail easily. Though other algorithms will work, 
>> it is
>>       RECOMMENDED that the right hand side contain some domain 
>> identifier
>> (either
>>       of the host itself or otherwise) such that the generator of the
>> message
>>      identifier can guarantee the uniqueness of the left hand side 
>> within
>> the scope
>>      of that domain.
>
> I think this is too much text for this "simple" property. I would like 
> basically what we have now (with one of the 3 options Alexey proposed 
> to clarify the "domain" syntax) together with the alternative of using 
> a "GUID" (with a non-normative reference to the uuid algorithm in 
> rfc4122). If "spam" is a concern then that should be mentioned in the 
> security considerations. There should be a general security statement 
> about exposing data "to the wild". Attendee addresses are likely to be 
> much more of an issue than the domain-based UID.
>
> A suggestion for a new Security Considerations sub-section:
>
> PRIVACY:
>
> iCalendar data is often made publicly available on the internet 
> through some form of publishing or distribution service. In such 
> cases, the authors of the data may prefer not to reveal information 
> about themselves. If this is the case, the calendar components in the 
> published calendar stream can use the "GUID" form for the UID property 
> value, as opposed to the "domain" form, which can expose details about 
> the creator's location etc. In addition, ORGANIZER and ATTENDEE 
> properties contain personal addressing information that may need to be 
> kept private. In that case, those properties can be removed from the 
> published iCalendar data. Other properties that contain user supplied 
> text could contain sensitive data - but for those it is up to the 
> creator of the component to not add such data knowing that it will be 
> published.
>

Date: Fri, 23 Feb 2007 10:08:43 -0500
From: Cyrus Daboo <[email-masked]>
To: Tim Hare <[email-masked]>, [email-masked]
Subject: RE: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the	UIDproperty

Hi Tim,

--On February 23, 2007 7:38:37 AM -0500 Tim Hare <[email-masked]> 
wrote:

> Here's a proposal for UID, although after I wrote it I'm not sure how
> effective it would be against spam (it was written in a short time
> period). Something along these lines could work, though; perhaps changing
> it to (uniqueID)-hostname-domain where the '@' is removed?
>
>
>
>
> Proposed Text for the UID property:
>
>  Description:  The "UID" itself MUST be a globally unique identifier.
>       The generator of the identifier MUST guarantee that the identifier
>       is unique.  There are several algorithms that can be used to
>       accomplish this.  The identifier is RECOMMENDED to be the
>       identical syntax to the [RFC2822] addr-spec, however to avoid
> issues        with unsolicited e-mail ("spam"), a false hostname SHOULD
> be used.  A good
>       method to assure uniqueness and security is to put a combination of
> the
>       current calendar date and time of day (i.e., formatted as in a
> DATE-TIME
>       value) along with some currently unique (perhaps sequential)
> identifier
>       available on the system (for example a procss id number) on
> left-hand side
>       of the "@", and on the right hand side put a non-existent hostname
> followed
>       by the domain name or a domain literal IP address of the host on
> which the
>       identifier was created.   Using a date/time value on the left hand
> side and
>       a domain name or domain literal on the right hand side makes it
> possible to
>       guarantee uniqueness since no two hosts should be using the same
> domain name
>       or IP address at the same time. Using the non-existent hostname on
> the
>
>       right-hand side allows the generator of the message identifier to
> avoid
>       unsolicited e-mail easily. Though other algorithms will work, it is
>       RECOMMENDED that the right hand side contain some domain identifier
> (either
>       of the host itself or otherwise) such that the generator of the
> message
>      identifier can guarantee the uniqueness of the left hand side within
> the scope
>      of that domain.

I think this is too much text for this "simple" property. I would like 
basically what we have now (with one of the 3 options Alexey proposed to 
clarify the "domain" syntax) together with the alternative of using a 
"GUID" (with a non-normative reference to the uuid algorithm in rfc4122). 
If "spam" is a concern then that should be mentioned in the security 
considerations. There should be a general security statement about exposing 
data "to the wild". Attendee addresses are likely to be much more of an 
issue than the domain-based UID.

A suggestion for a new Security Considerations sub-section:

PRIVACY:

iCalendar data is often made publicly available on the internet through 
some form of publishing or distribution service. In such cases, the authors 
of the data may prefer not to reveal information about themselves. If this 
is the case, the calendar components in the published calendar stream can 
use the "GUID" form for the UID property value, as opposed to the "domain" 
form, which can expose details about the creator's location etc. In 
addition, ORGANIZER and ATTENDEE properties contain personal addressing 
information that may need to be kept private. In that case, those 
properties can be removed from the published iCalendar data. Other 
properties that contain user supplied text could contain sensitive data - 
but for those it is up to the creator of the component to not add such data 
knowing that it will be published.

-- 
Cyrus Daboo

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty
Date: Fri, 23 Feb 2007 07:38:37 -0500

Here's a proposal for UID, although after I wrote it I'm not sure how
effective it would be against spam (it was written in a short time period).
Something along these lines could work, though; perhaps changing it to
(uniqueID)-hostname-domain where the '@' is removed?

Proposed Text for the UID property:

 Description:  The "UID" itself MUST be a globally unique identifier.
      The generator of the identifier MUST guarantee that the identifier
      is unique.  There are several algorithms that can be used to
      accomplish this.  The identifier is RECOMMENDED to be the
      identical syntax to the [RFC2822] addr-spec, however to avoid issues 
      with unsolicited e-mail ("spam"), a false hostname SHOULD be used.  A
good 
      method to assure uniqueness and security is to put a combination of
the 
      current calendar date and time of day (i.e., formatted as in a
DATE-TIME 
      value) along with some currently unique (perhaps sequential)
identifier 
      available on the system (for example a procss id number) on left-hand
side
      of the "@", and on the right hand side put a non-existent hostname
followed
      by the domain name or a domain literal IP address of the host on which
the
      identifier was created.   Using a date/time value on the left hand
side and
      a domain name or domain literal on the right hand side makes it
possible to
      guarantee uniqueness since no two hosts should be using the same
domain name
      or IP address at the same time. Using the non-existent hostname on the

      right-hand side allows the generator of the message identifier to
avoid 
      unsolicited e-mail easily. Though other algorithms will work, it is 
      RECOMMENDED that the right hand side contain some domain identifier
(either
      of the host itself or otherwise) such that the generator of the
message 
     identifier can guarantee the uniqueness of the left hand side within
the scope
     of that domain.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Kiff
Sent: Friday, February 23, 2007 1:52 AM
To: Cyrus Daboo
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the
UIDproperty

Cyrus Daboo wrote:

> Hi Martin,
>
> --On February 22, 2007 4:39:48 PM +0100 Martin Kiff 
> <[email-masked]> wrote:
>
>> If you put an .ics file on the web, you've published a lot of 
>> email-like addresses; be prepared for them to be picked up by 
>> Spam-harvesters. I think the spec should suggest some other format.
>
>
> The reality is a lot of clients tend to use a "GUID". We should 
> probably add that as an alternative recommended format.
>
I think it would be better - or I've seen a URL referring to just that
single event which keeps the transparency (GUID's would be opaque? There
would be no way by eye to confirm that they are unique?) I think in DNS data
the contacts are user-part.domain-part

> As to spam harvesting, its only the domain portion that is a valid 
> "network address", and frankly that is likely to have much more 
> exposure via email, so I would not be more concerned about having that 
> in .ics data than the current state of affairs.
>
Let's say, it is something I've seen in practice... messages bouncing off
the spam defences sent to addresses taken from .ics files.

No, they wouldn't (shouldn't!) be real addresses but they load your ISP
connection and add stress to your defences and it's a bit tough if you have
a 'catch all' mailbox for your domain.

Regards, Martin

Date: Fri, 23 Feb 2007 07:51:48 +0100
From: Martin Kiff <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property
Cc: [email-masked]

Cyrus Daboo wrote:

> Hi Martin,
>
> --On February 22, 2007 4:39:48 PM +0100 Martin Kiff 
> <[email-masked]> wrote:
>
>> If you put an .ics file on the web, you've published a lot of email-like
>> addresses; be prepared for them to be picked up by Spam-harvesters. I
>> think the spec should suggest some other format.
>
>
> The reality is a lot of clients tend to use a "GUID". We should 
> probably add that as an alternative recommended format.
>
I think it would be better - or I've seen a URL referring to just that 
single event which keeps the transparency (GUID's would be opaque? There 
would be no way by eye to confirm that they are unique?) I think in DNS 
data the contacts are user-part.domain-part

> As to spam harvesting, its only the domain portion that is a valid 
> "network address", and frankly that is likely to have much more 
> exposure via email, so I would not be more concerned about having that 
> in .ics data than the current state of affairs.
>
Let's say, it is something I've seen in practice... messages bouncing 
off the spam defences sent to addresses taken from .ics files.

No, they wouldn't (shouldn't!) be real addresses but they load your ISP 
connection and add stress to your defences and it's a bit tough if you 
have a 'catch all' mailbox for your domain.

Regards, Martin

Date: Thu, 22 Feb 2007 10:59:50 -0500
From: Cyrus Daboo <[email-masked]>
To: Martin Kiff <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID	property

Hi Martin,

--On February 22, 2007 4:39:48 PM +0100 Martin Kiff <[email-masked]> 
wrote:

> If you put an .ics file on the web, you've published a lot of email-like
> addresses; be prepared for them to be picked up by Spam-harvesters. I
> think the spec should suggest some other format.

The reality is a lot of clients tend to use a "GUID". We should probably 
add that as an alternative recommended format.

As to spam harvesting, its only the domain portion that is a valid "network 
address", and frankly that is likely to have much more exposure via email, 
so I would not be more concerned about having that in .ics data than the 
current state of affairs.

-- 
Cyrus Daboo

Date: Thu, 22 Feb 2007 15:45:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Martin Kiff <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property
Cc: [email-masked]

Martin Kiff wrote:

> Alexey Melnikov wrote:
>
>>> Description: The "UID" itself MUST be a globally unique identifier.
>>> The generator of the identifier MUST guarantee that the identifier
>>> is unique. There are several algorithms that can be used to
>>> accomplish this. The identifier is RECOMMENDED to be the
>>> identical syntax to the [RFC2822] addr-spec.
>>
>> The advice given in the last sentence seems reasonable...
>
> Hummmm, but....
>
> If you put an .ics file on the web, you've published a lot of 
> email-like addresses; be prepared for them to be picked up by 
> Spam-harvesters.

So? They are not email addresses.

> I think the spec should suggest some other format.

Date: Thu, 22 Feb 2007 16:39:48 +0100
From: Martin Kiff <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property

Alexey Melnikov wrote:

> [I've sent this issue to Bernard before the San Diego IETF]
>
>> 3.8.4.7. Unique Identifier
>>
>> Property Name: UID
>>
>> Purpose: This property defines the persistent, globally unique
>> identifier for the calendar component.
>
>
> [...]
>
>> Description: The "UID" itself MUST be a globally unique identifier.
>> The generator of the identifier MUST guarantee that the identifier
>> is unique. There are several algorithms that can be used to
>> accomplish this. The identifier is RECOMMENDED to be the
>> identical syntax to the [RFC2822] addr-spec.
>
>
> The advice given in the last sentence seems reasonable...

Hummmm, but....

If you put an .ics file on the web, you've published a lot of email-like 
addresses; be prepared for them to be picked up by Spam-harvesters. I 
think the spec should suggest some other format.

Regards, Martin

Date: Thu, 22 Feb 2007 15:56:04 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts in 5 minutes!

Server jabber.ietf.org, room calsify ([email-masked]).

Eliot

Date: Thu, 22 Feb 2007 12:47:13 +0000
From: Alexey Melnikov <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property

[I've sent this issue to Bernard before the San Diego IETF]

> 3.8.4.7. Unique Identifier
>
> Property Name: UID
>
> Purpose: This property defines the persistent, globally unique
> identifier for the calendar component.

[...]

> Description: The "UID" itself MUST be a globally unique identifier.
> The generator of the identifier MUST guarantee that the identifier
> is unique. There are several algorithms that can be used to
> accomplish this. The identifier is RECOMMENDED to be the
> identical syntax to the [RFC2822] addr-spec.

The advice given in the last sentence seems reasonable, but when one
starts to look into addr-spec ABNF, one would find that the addr-spec
allows for folding whitespaces (FWS) in various place (and I don't think
use of FWS is a good idea in this case).
 From RFC 2822, section 3.4.1:

addr-spec = local-part "@" domain

local-part = dot-atom / quoted-string / obs-local-part

domain = dot-atom / domain-literal / obs-domain

domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent = dtext / quoted-pair

dtext = NO-WS-CTL / ; Non white space controls

%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"

where dot-atom is defined as:

dot-atom = [CFWS] dot-atom-text [CFWS]

obs-local-part and obs-domain also allow for FWS.

Suggestions:

Option 1) RECOMMEND using <id-left-strict>@<id-right-strict>, which are
defined as follows:

id-left-strict = dot-atom-text / no-fold-quote

id-right-strict = dot-atom-text / no-fold-literal / domain-literal-strict

domain-literal-strict = "[" *dcontent "]"

(all used non terminals come from RFC 2822)

Option 2) Keep the existing recommendation, but add a clarifying
statement that FWS or CFWS MUST NOT be used inside addr-spec.
Option 3) Reference the <mailbox> syntax in section 4.1.2 of RFC 2821
(SMTP), which defines:

Mailbox = Local-part "@" Domain

and doesn't allow for any extra folding whitespaces or RFC 2822 "comments".

====
My personal preference is option # 3. Bernard also likes # 3 and Cyrus
prefers # 2.

Date: Thu, 22 Feb 2007 12:51:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Question about section 3.1: name ABNF

 >3.1.  Content Lines
[...]
 >      contentline        = name *(";" param ) ":" value CRLF
 >      ; This ABNF is just a general definition for an initial parsing
 >      ; of the content line into its property name, parameter list,
 >      ; and value string
 >
 >      ; When parsing a content line, folded lines MUST first
 >      ; be unfolded according to the unfolding procedure
 >      ; described above. When generating a content line, lines
 >      ; longer than 75 octets SHOULD be folded according to
 >      ; the folding procedure described above.
 >
 >      name               = x-name / iana-token
 >
 >      iana-token = 1*(ALPHA / DIGIT / "-")

The name can start with a digit: is this a bug or a feature?

Date: Thu, 22 Feb 2007 12:56:54 +0000
From: Alexey Melnikov <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Use of URI parameters in ORGANIZER/ATTENDEE properties, DELEGATED-FROM parameter, etc.

Cyrus Daboo wrote:

> Alexey Melnikov wrote:
>
>> mailto: URLs allow for parameters after the '?' character. Should
>> iCalendar prohibit use of such parameters in ORGANIZER/ATTENDEE
>> properties (and DELEGATED-FROM, etc parameters)?
>
> Actually ATTENDEE is used in email action alarms, and in that case 
> using "?" parameters might be handy. However, we really ought to have 
> a generic "URI" action for alarms and perhaps that could accept the 
> more general mailto format.

Either way, I think the document needs to discuss where URI parameters 
are acceptable and where they are not.

Date: Thu, 22 Feb 2007 12:46:48 +0000
From: Alexey Melnikov <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 3.2.8: Format Type ABNF

[Another one of the "old" issues]

> 3.2.8. Format Type
>
> Parameter Name: FMTTYPE
>
> Purpose: To specify the content type of a referenced object.
>
> Format Definition: The property parameter is defined by the following
> notation:
>
> fmttypeparam = "FMTTYPE" "=" iana-token
> ; A IANA registered content type
> / x-name
> ; A non-standard content type

The ABNF is not actually correct, because FMTTYPE is supposed to look 
like <mimetype>/<mimesubtype>.
However RFC 2445 didn't allow '/' in ABNF:

     fmttypeparam       = "FMTTYPE" "=" iana-token
                                        ; A IANA registered content type
                                     / x-name
                                        ; A non-standard content type

     iana-token = 1*(ALPHA / DIGIT / "-")
     ; iCalendar identifier registered with IANA

     x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
     ; Reservered for experimental use. Not intended for use in
     ; released products.

Bernard wrote:

> Should it be:
>
> fmttypeparam = "FMTTYPE" "=" type "/" subtype *(";" parameter)
> ; Where "type", "subtype", and "parameter" are defined in
> ; section 5.1 of [RFC2045]

Bernard argued that <parameter>s are needed, for example to specify 
charset to text/plain. I think some interop testing of this needs to be 
done.

I've found updated ABNF for type/subtype in Section 4.2 of RFC 4288, so 
the final suggestion is:

fmttypeparam = "FMTTYPE" "=" type-name "/" subtype-name *(";" parameter)
; Where "type-name", "subtype-name" are defined in
; section 4.2 of [RFC4288], and  "parameter" is defined in
; section 5.1 of [RFC2045].

And [RFC4288] needs to be added to the Normative References.

Date: Wed, 21 Feb 2007 19:16:23 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.
Cc: [email-masked]
Reply-To: [email-masked]

Ack, sorry, rules with a BYSETPOS with non-negative indices don't have
this property either but I think that's a small enough set of rules
that the principal is one that shouldn't be violated needlessly.

mike

On 21/02/07, Mike Samuel <[email-masked]> wrote:
> My objection to your interpretation of
> RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30 is that it does not have the
> property that
>
>   for every RRULE r (with no count) and a DTSTART d1, if I pick a date
> d2 from the series (r, d1)
>   then the series (r, d2) should be a tail of (r, d1)
>
>
> On 19/02/07, Nigel Swinson <[email-masked]> wrote:
> >
> >
> > Please could you confirm to me that the following does not include the 15th
> > of February:
> >
> > DTSTART;VALUE=DATE:20070130
> > RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
> >
> > Nor does this include any date in February:
> >
> >
> >
> > DTSTART;VALUE=DATE:20070130
> > RRULE:FREQ=MONTHLY;BYMONTHDAY=1,-1
> >
> >
> > Whereas these would:
> >
> >
> > DTSTART;VALUE=DATE:20070115
> > RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
> > EXDATE:20070115
> >
> >
> > DTSTART;VALUE=DATE:20070130
> > RRULE:FREQ=DAILY;BYMONTHDAY=15,30
> >
> >
> > I don't find the above particularly obvious, so in case it helps, my
> > thinking is that you use DTSTART and FREQ to create the initial recurrence
> > set, and then refine/expand it using the BYXXX rules.  As there is no 30th
> > of Feb, the initial recurrence set contains no dates in February, and hence
> > we have no date in february to expand or refine to create additional dates
> > in february in the context of a monthly rule.
> >
> > If I am right, and you also consider the above not particularly obvious,
> > perhaps it worth refining this paragraph in RFC2445 to spell out the
> > algorithm.  I suggest we move the "invalid date" paragraph down one, and
> > then:
> >
> > http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.10
> >
> >       Information, not contained in the rule, necessary to determine the
> >       various recurrence instance start time and dates are derived from
> >       the Start Time ("DTSTART") component attribute.  For example,
> >       "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
> >       month or a time.  This information would be the same as what is
> >       specified for "DTSTART".
> >
> >       Recurrence rules may generate recurrence instances with invalid
> >       date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
> >       on a day where the local time is moved forward by an hour at 1:00
> >       AM).  Such recurrence instances MUST be ignored and MUST NOT be
> >       counted as part of the recurrence set.
> > +    Should the combination of DTSTART and FREQ itself create
> > +    recurrences that lie on non existant dates, then you end up skipping
> > +    entire intervals.  For example "DTSTART;VALUE=DATE:20070130" with
> > +    "FREQ=MONTHLY" will never contain any instances in February regardless
> > +    of what BYXXX rule parts are specified.
> >
> >       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.
> >
> > Cheers
> >
> >
> > Nigel

Date: Wed, 21 Feb 2007 19:10:35 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.
Cc: [email-masked]
Reply-To: [email-masked]

My objection to your interpretation of
RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30 is that it does not have the
property that

  for every RRULE r (with no count) and a DTSTART d1, if I pick a date
d2 from the series (r, d1)
  then the series (r, d2) should be a tail of (r, d1)

On 19/02/07, Nigel Swinson <[email-masked]> wrote:
>
>
> Please could you confirm to me that the following does not include the 15th
> of February:
>
> DTSTART;VALUE=DATE:20070130
> RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
>
> Nor does this include any date in February:
>
>
>
> DTSTART;VALUE=DATE:20070130
> RRULE:FREQ=MONTHLY;BYMONTHDAY=1,-1
>
>
> Whereas these would:
>
>
> DTSTART;VALUE=DATE:20070115
> RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
> EXDATE:20070115
>
>
> DTSTART;VALUE=DATE:20070130
> RRULE:FREQ=DAILY;BYMONTHDAY=15,30
>
>
> I don't find the above particularly obvious, so in case it helps, my
> thinking is that you use DTSTART and FREQ to create the initial recurrence
> set, and then refine/expand it using the BYXXX rules.  As there is no 30th
> of Feb, the initial recurrence set contains no dates in February, and hence
> we have no date in february to expand or refine to create additional dates
> in february in the context of a monthly rule.
>
> If I am right, and you also consider the above not particularly obvious,
> perhaps it worth refining this paragraph in RFC2445 to spell out the
> algorithm.  I suggest we move the "invalid date" paragraph down one, and
> then:
>
> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.10
>
>       Information, not contained in the rule, necessary to determine the
>       various recurrence instance start time and dates are derived from
>       the Start Time ("DTSTART") component attribute.  For example,
>       "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
>       month or a time.  This information would be the same as what is
>       specified for "DTSTART".
>
>       Recurrence rules may generate recurrence instances with invalid
>       date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
>       on a day where the local time is moved forward by an hour at 1:00
>       AM).  Such recurrence instances MUST be ignored and MUST NOT be
>       counted as part of the recurrence set.
> +    Should the combination of DTSTART and FREQ itself create
> +    recurrences that lie on non existant dates, then you end up skipping
> +    entire intervals.  For example "DTSTART;VALUE=DATE:20070130" with
> +    "FREQ=MONTHLY" will never contain any instances in February regardless
> +    of what BYXXX rule parts are specified.
>
>       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.
>
> Cheers
>
>
> Nigel

Date: Wed, 21 Feb 2007 12:55:43 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.
Cc: [email-masked]
Reply-To: [email-masked]

On 21/02/07, Nigel Swinson <[email-masked]> wrote:
> > Am Dienstag, 20. Februar 2007 schrieb Nigel Swinson:
> > > I don't find the above particularly obvious, so in case it helps, my
> > > thinking is that you use DTSTART and FREQ to create the initial recurrence
> > > set, and then refine/expand it using the BYXXX rules.
> >
> > Isn't the RFC saying the exact opposite? First you apply the FREQ and the BY*
> > rule parts, and only what's missing after that is taken from DTSTART. So if
> > no BYDAY was given in your examples, then the event would not occur in
> > february. But any BYDAY rule part overrides the 30th and the event will occur
> > in february.
> > "Information, not contained in the rule, necessary to determine the various
> > recurrence instance start time and dates are derived from the Start Time
> > (DTSTART) entry attribute."
>
> I could see this going either way, hence I thought it worthy of a mail.  Judging by Cyrus' response, I'm not the first to stumble on this subtlety.
>
> I guess the problem is you have to have some way of representing the recurrence set as you go along.  Start with an empty set, then apply FREQ and INTERVAL from DTSTART, then the BYX parts in the specified order.  It seems obvious to use Date/DateTime objects to represent these dates where you have a valid recurrence set after each step of processing.  But doing this means you have to set the year, month, day, (hour, minute, second) to something, or else carry about some kind of mask to say what does, and does not have valid data.
>
> Given that iCalender tells us that DTSTART is to be the first instance, and we are to use DTSTART to get information not already available in the BYX rule parts, it seems to create a much simpler, less error prone algorithm to just take DTSTART + n*FREQ to create a set of dates, filtering out those that can't exist, and apply the BYX rule parts.  Then at each stage in the processing, you have a valid set of dates.

I think if you define
  T0 === the greatest date that starts a period that is <= DTSTART
and instead of DTSTART + n * FREQ you use
  T0 + n * INTERVAL * FREQ
you can make this approach work.

You just have to filter out from the first period any that are < DTSTART.

Either way, your algorithm doesn't require that the entire set be
discarded if a single date is nonsensical.

See http://google-rfc-2445.googlecode.com/svn/trunk/src/com/google/ical/iter/RRuleIteratorImpl.java
for an alternate algorithm which uses separate producers of years,
months, and days.  Each by*** rule can be treated as either a producer
or a filter which allows some degree of flexibility in choosing the
combination of producers/filters that needs to do the least work.

> But doing it this way means that as in my example, a DTSTART of Jan 30th and a FREQ of MONTHLY would automatically eliminate any recurrences in Feb.  I can't say I'm too sad about that, as the rule can be rewritten as a DAILY instead to ensure it doesn't exclude February.
>
> So I'd like to push for permitting this kind of algorithm.
>
> Even if you are not persuaded, and I suspect you are not, then I still think it would be worth spelling out perhaps in numbered steps an algorithm that will meet the philosophy of the standard.  Trying to extract this from several paragraphs of prose is pretty tricky and is only going to result in interoperability problems.  If people agree to this in principle, then I'd be happy to have a go at some suggested text?
>
> Nigel
>

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 01b45ac7be28df977b46494d3029e009
X-Spam-Score-Summary: 2, 0, 0, d4972121ed74af80, 5c6910fe347e04a0, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1461:1513:1515:1516:1518:1521:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2553:2559:2562:2693:2731:2828:2892:2903:3027:3355:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4559: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: <[email-masked]>
Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.
Date: Wed, 21 Feb 2007 17:06:33 -0000

> Am Dienstag, 20. Februar 2007 schrieb Nigel Swinson:
> > I don't find the above particularly obvious, so in case it helps, my
> > thinking is that you use DTSTART and FREQ to create the initial =
recurrence
> > set, and then refine/expand it using the BYXXX rules.
>=20
> Isn't the RFC saying the exact opposite? First you apply the FREQ and =
the BY*=20
> rule parts, and only what's missing after that is taken from DTSTART. =
So if=20
> no BYDAY was given in your examples, then the event would not occur in =

> february. But any BYDAY rule part overrides the 30th and the event =
will occur=20
> in february.=20
> "Information, not contained in the rule, necessary to determine the =
various=20
> recurrence instance start time and dates are derived from the Start =
Time=20
> (DTSTART) entry attribute."

I could see this going either way, hence I thought it worthy of a mail.  =
Judging by Cyrus' response, I'm not the first to stumble on this =
subtlety. =20

I guess the problem is you have to have some way of representing the =
recurrence set as you go along.  Start with an empty set, then apply =
FREQ and INTERVAL from DTSTART, then the BYX parts in the specified =
order.  It seems obvious to use Date/DateTime objects to represent these =
dates where you have a valid recurrence set after each step of =
processing.  But doing this means you have to set the year, month, day, =
(hour, minute, second) to something, or else carry about some kind of =
mask to say what does, and does not have valid data.

Given that iCalender tells us that DTSTART is to be the first instance, =
and we are to use DTSTART to get information not already available in =
the BYX rule parts, it seems to create a much simpler, less error prone =
algorithm to just take DTSTART + n*FREQ to create a set of dates, =
filtering out those that can't exist, and apply the BYX rule parts.  =
Then at each stage in the processing, you have a valid set of dates.

But doing it this way means that as in my example, a DTSTART of Jan 30th =
and a FREQ of MONTHLY would automatically eliminate any recurrences in =
Feb.  I can't say I'm too sad about that, as the rule can be rewritten =
as a DAILY instead to ensure it doesn't exclude February.

So I'd like to push for permitting this kind of algorithm.

Even if you are not persuaded, and I suspect you are not, then I still =
think it would be worth spelling out perhaps in numbered steps an =
algorithm that will meet the philosophy of the standard.  Trying to =
extract this from several paragraphs of prose is pretty tricky and is =
only going to result in interoperability problems.  If people agree to =
this in principle, then I'd be happy to have a go at some suggested =
text?

Nigel

To: [email-masked]
From: [email-masked]
Date: Wed, 21 Feb 2007 10:50:02 -0500
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-03.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-03.txt
	Pages		: 21
	Date		: 2007-2-21
	
This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
   Calendaring entries defined by the iCalendar Object Model (iCAL) are
   composed using constructs from RFC 2822, RFC 2045, RFC 2046,
   RFC 2047 and RFC 2049.

   This document is a product of Calendaring and Scheduling Standards
   Simplification (calsify) working group. More information about the
   IETF CALSIFY working group activities can be found on the IETF web
   site at <http://www.ietf.org/html.charters/calsify-charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-calsify-rfc2447bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2447bis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2447bis-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2447bis-03.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.
Date: Tue, 20 Feb 2007 07:38:03 +0100

Am Dienstag, 20. Februar 2007 schrieb Nigel Swinson:
> I don't find the above particularly obvious, so in case it helps, my
> thinking is that you use DTSTART and FREQ to create the initial recurrence
> set, and then refine/expand it using the BYXXX rules.

Isn't the RFC saying the exact opposite? First you apply the FREQ and the BY* 
rule parts, and only what's missing after that is taken from DTSTART. So if 
no BYDAY was given in your examples, then the event would not occur in 
february. But any BYDAY rule part overrides the 30th and the event will occur 
in february. 
"Information, not contained in the rule, necessary to determine the various 
recurrence instance start time and dates are derived from the Start Time 
(DTSTART) entry attribute."

Cheers,
Reinhold

- -- 

Date: Mon, 19 Feb 2007 23:43:01 -0500
From: Cyrus Daboo <[email-masked]>
To: George Sexton <[email-masked]>, ietf-calsify <[email-masked]>
Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.

Hi George,

--On February 19, 2007 9:19:33 PM -0700 George Sexton 
<[email-masked]> wrote:

>> Please could you confirm to me that the following does not include the
>> 15th of February:
>>
>> DTSTART;VALUE=DATE:20070130
>> RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
> No. This would include the 15th of February only. Why do you think it
> would not apply to February? The FREQ is monthly, and February is a month
> too.

I think I agree with George on this - 15th February should be included. 
That is in spite of the fact that an implementation I wrote does not do 
that - oh well :-(

-- 
Cyrus Daboo

Date: Mon, 19 Feb 2007 21:19:33 -0700
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: ietf-calsify <[email-masked]>
Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.

Nigel Swinson wrote:
> Please could you confirm to me that the following does not include the 
> 15th of February:
>  
> DTSTART;VALUE=DATE:20070130
> RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
No. This would include the 15th of February only. Why do you think it 
would not apply to February? The FREQ is monthly, and February is a 
month too.
>  
> Nor does this include any date in February:
>  
> DTSTART;VALUE=DATE:20070130
> RRULE:FREQ=MONTHLY;BYMONTHDAY=1,-1
No, this would include the 1st of February, and the  28th (or 29th for 
leap years).
>  
> Whereas these would:
>
> DTSTART;VALUE=DATE:20070115
> RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
> EXDATE:20070115
Agan, this is the 15th of February only.
>  
> DTSTART;VALUE=DATE:20070130
> RRULE:FREQ=DAILY;BYMONTHDAY=15,30
This also would include only the 15th of February.
>  
>  
> I don't find the above particularly obvious, so in case it helps, my 
> thinking is that you use DTSTART and FREQ to create the initial 
> recurrence set, and then refine/expand it using the BYXXX rules.  As 
> there is no 30th of Feb, the initial recurrence set contains no dates 
> in February, and hence we have no date in february to expand or refine 
> to create additional dates in february in the context of a monthly rule.
>  
> If I am right, and you also consider the above not particularly 
> obvious, perhaps it worth refining this paragraph in RFC2445 to spell 
> out the algorithm.  I suggest we move the "invalid date" paragraph 
> down one, and then:
>  
> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.10
>  
>       Information, not contained in the rule, necessary to determine the
>       various recurrence instance start time and dates are derived from
>       the Start Time ("DTSTART") component attribute.  For example,
>       "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
>       month or a time.  This information would be the same as what is
>       specified for "DTSTART".
>  
>       Recurrence rules may generate recurrence instances with invalid
>       date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
>       on a day where the local time is moved forward by an hour at 1:00
>       AM).  Such recurrence instances MUST be ignored and MUST NOT be
>       counted as part of the recurrence set.
> +    Should the combination of DTSTART and FREQ itself create
> +    recurrences that lie on non existant dates, then you end up skipping
> +    entire intervals.  For example "DTSTART;VALUE=DATE:20070130" with
> +    "FREQ=MONTHLY" will never contain any instances in February 
> regardless
> +    of what BYXXX rule parts are specified.
>  
>       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.
> Cheers
>  
> Nigel
> ------------------------------------------------------------------------
>

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

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 25d569e413820ea199895ee0491dc9e3
X-Spam-Score-Summary: 2, 0, 0, a53aceec76df4c0a, 0ccc676e4aeb5ad6, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:962:967:973:983:988:989:1155:1156:1189:1208:1212:1221:1261:1308:1309:1313:1314:1345:1431:1436:1437:1487:1515:1516:1517:1521:1535:1544:1575:1587:1588:1589:1592:1594:1683:1685:1711:1730:1776:1792:2068:2069:2073:2075:2078:2198:2199:2525:2553:2557:2559:2564:2682:2685:2693:2731:2857:2859:2892:2909:2933:2937:2939:2942:2945:2947:2951:2954:3022:3355:3586:3642:3769:3770:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:4119:4250:4321:4605: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: <[email-masked]>
Date: Tue, 20 Feb 2007 00:00:54 -0000
Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st.

This is a multi-part message in MIME format.

------=_NextPart_000_0149_01C75482.30C33690
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Please could you confirm to me that the following does not include the =
15th of February:

DTSTART;VALUE=3DDATE:20070130
RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D15,30

Nor does this include any date in February:

DTSTART;VALUE=3DDATE:20070130
RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D1,-1

Whereas these would:

DTSTART;VALUE=3DDATE:20070115
RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D15,30
EXDATE:20070115
=20
DTSTART;VALUE=3DDATE:20070130
RRULE:FREQ=3DDAILY;BYMONTHDAY=3D15,30

I don't find the above particularly obvious, so in case it helps, my =
thinking is that you use DTSTART and FREQ to create the initial =
recurrence set, and then refine/expand it using the BYXXX rules.  As =
there is no 30th of Feb, the initial recurrence set contains no dates in =
February, and hence we have no date in february to expand or refine to =
create additional dates in february in the context of a monthly rule.

If I am right, and you also consider the above not particularly obvious, =
perhaps it worth refining this paragraph in RFC2445 to spell out the =
algorithm.  I suggest we move the "invalid date" paragraph down one, and =
then:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.1=
0

      Information, not contained in the rule, necessary to determine the
      various recurrence instance start time and dates are derived from
      the Start Time ("DTSTART") component attribute.  For example,
      "FREQ=3DYEARLY;BYMONTH=3D1" doesn't specify a specific day within =
the
      month or a time.  This information would be the same as what is
      specified for "DTSTART".

      Recurrence rules may generate recurrence instances with invalid
      date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
      on a day where the local time is moved forward by an hour at 1:00
      AM).  Such recurrence instances MUST be ignored and MUST NOT be
      counted as part of the recurrence set.
+    Should the combination of DTSTART and FREQ itself create
+    recurrences that lie on non existant dates, then you end up =
skipping
+    entire intervals.  For example "DTSTART;VALUE=3DDATE:20070130" with
+    "FREQ=3DMONTHLY" will never contain any instances in February =
regardless
+    of what BYXXX rule parts are specified.

      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.

Cheers

Nigel
------=_NextPart_000_0149_01C75482.30C33690
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3Dfile://E:\Nigel\>
<STYLE>DIV {
	FONT-SIZE: 10pt; FONT-FAMILY: vernada, sans-serif
}
P {
	FONT-SIZE: 10pt; FONT-FAMILY: vernada, sans-serif
}
 {
	FONT-SIZE: 10pt; FONT-FAMILY: vernada, sans-serif
}
LI {
	FONT-SIZE: 10pt; FONT-FAMILY: vernada, sans-serif
}
H1 {
	COLOR: #a11100
}
H2 {
	COLOR: #336600
}
H3 {
	COLOR: #003366
}
TH {
	COLOR: #003366
}
.note {
	MARGIN-LEFT: 20px; COLOR: #000000; MARGIN-RIGHT: 20px; =
BACKGROUND-COLOR: #cccccc
}
STRONG {
	COLOR: #a11100
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Please could you confirm to me that the following does not include =
the 15th=20
of February:</DIV>
<DIV>&nbsp;</DIV>
<DIV>DTSTART;VALUE=3DDATE:20070130</DIV>
<DIV>RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D15,30</DIV>
<DIV>&nbsp;</DIV>
<DIV>Nor does this include any date in February:</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>
<DIV>DTSTART;VALUE=3DDATE:20070130</DIV>
<DIV>RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D1,-1</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>Whereas these would:</DIV></DIV></DIV></DIV>
<DIV><BR>
<DIV>DTSTART;VALUE=3DDATE:20070115</DIV>
<DIV>RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D15,30</DIV>
<DIV>EXDATE:20070115</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>DTSTART;VALUE=3DDATE:20070130</DIV>
<DIV>RRULE:FREQ=3DDAILY;BYMONTHDAY=3D15,30</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I don't find the above particularly obvious, so in case it helps, =
my=20
thinking is that you use DTSTART and FREQ to create the initial =
recurrence set,=20
and then refine/expand it using the BYXXX rules.&nbsp; As there is no =
30th of=20
Feb, the initial recurrence set contains no dates in February, and hence =
we have=20
no date in february to expand or refine to create additional dates in =
february=20
in the context of a monthly rule.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If I am right, and you also consider the above not particularly =
obvious,=20
perhaps it worth refining this paragraph in RFC2445 to spell out the=20
algorithm.&nbsp; I suggest we move the "invalid date" paragraph down =
one, and=20
then:</DIV>
<DIV>&nbsp;</DIV>
<DIV><A=20
href=3D"http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#secti=
on-3.3.10">http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#se=
ction-3.3.10</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Information, not contained in the =
rule,=20
necessary to determine the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; various =
recurrence=20
instance start time and dates are derived =
from<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the Start Time ("DTSTART") component attribute.&nbsp; For=20
example,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "FREQ=3DYEARLY;BYMONTH=3D1" =
doesn't=20
specify a specific day within the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
month or a=20
time.&nbsp; This information would be the same as what=20
is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specified for "DTSTART".</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Recurrence rules may generate =
recurrence=20
instances with invalid<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; date (e.g., =
February=20
30) or nonexistent local time (e.g., 1:30 =
AM<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
on a day where the local time is moved forward by an hour at=20
1:00<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AM).&nbsp; Such recurrence =
instances MUST=20
be ignored and MUST NOT be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; counted as =
part of=20
the recurrence set.<BR>+&nbsp;&nbsp;&nbsp; Should the combination of =
DTSTART and=20
FREQ itself create</DIV>
<DIV>+&nbsp;&nbsp;&nbsp; recurrences that lie on non existant dates, =
then you=20
end up skipping</DIV>
<DIV>+&nbsp;&nbsp;&nbsp; entire intervals.&nbsp; For example=20
"DTSTART;VALUE=3DDATE:20070130" with</DIV>
<DIV>+&nbsp;&nbsp;&nbsp; "FREQ=3DMONTHLY" will never contain any =
instances in=20
February regardless</DIV>
<DIV>+&nbsp;&nbsp;&nbsp; of what BYXXX rule parts are specified.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If multiple BYxxx rule parts are =
specified,=20
then after evaluating<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the specified =
FREQ and=20
INTERVAL rule parts, the BYxxx rule =
parts<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are=20
applied to the current set of evaluated occurrences in=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; following order: BYMONTH, =
BYWEEKNO,=20
BYYEARDAY, BYMONTHDAY, BYDAY,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BYHOUR,=20
BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL=20
are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; evaluated.<BR></DIV>
<DIV>Cheers</DIV>
<DIV>
<DIV>&nbsp;</DIV>
<DIV>Nigel</DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_0149_01C75482.30C33690--

Date: Mon, 19 Feb 2007 16:33:28 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, [email-masked]
Subject: Re: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day	Events and DTEND]

Hi Bernard,

--On February 19, 2007 11:39:23 AM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> The same way that the DTEND property specifies the non-inclusive end
> of events, the DUE property should be handled the same way for to-dos.

+1

> The implication here is that any application that presents a DUE property
> of DATE value type as a "Due date" needs to substract one day to its value
> since for an end user if some to-do is due on Feburary 14, 2007 he has
> until the end of the day to complete the to-do (i.e., until 23:59:59 on
> February 14, 2007). I've been told that some applications are presenting
> this value as "Due by" to avoid this ambiguity.

>From an analysis of a few clients it does look like the "due date" they 
display to users is the same value as gets used in the DUE property. The 
difference between "due on" and "due by" needs to be clear to users - but 
that distinction can be hard to represent. There is certainly a lot more 
variability in the way tasks/to-dos are presented to users that it would be 
hard come up with one true way to do that - but we should at least make 
explicitly clear what DUE represents in iCalendar data.

-- 
Cyrus Daboo

Date: Mon, 19 Feb 2007 22:30:43 +0100
From: Martin Kiff <[email-masked]>
To: [email-masked]
Subject: Re: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day	Events and DTEND]

Bernard Desruisseaux wrote:

> I would like to extend the scope of issue 10 to also cover the handling
> of the DUE property when specified as a DATE value in a VTODO component.
> ... 
> The following are examples of to-dos scheduled to start at 00:00:00 on
> February 14, 2007 and expected to be completed at the exact same time.
>    ...
>
>    DTSTART:20070214T000000
>    DUE:20070214T000000
>
>    DTSTART;VALUE=DATE:20070214
>    DUE;VALUE=DATE:20070214
>
> The implication here is that any application that presents a DUE property
> of DATE value type as a "Due date" needs to substract one day to its 
> value
> since for an end user if some to-do is due on Feburary 14, 2007 he has
> until the end of the day to complete the to-do (i.e., until 23:59:59 on
> February 14, 2007). I've been told that some applications are presenting
> this value as "Due by" to avoid this ambiguity.
>

My assumption is that DATE-TIME gives an instant; a time of zero extent. 
If you say DTSTART:20070214T000000 then that's the instant at the start 
of that second. (I think we are not really talking about a time with an 
extent of a second). That also seems to be understood when you talk 
about time, you say '3 o'clock'. That is 'an instant'...

However when you talk about dates, you talk about something which 
extends 24 hours (exception cases, mumble, mumble) _and_ you are also 
choosing a measure with lower precision. The way people talk about dates 
and times differs, at least in English, with the 'naive' view that a 
date extends to the end of the period... (and hence the need for 'due by')

Why should DUE;VALUE=DATE:20070215 particularly mean by the end of the 
previous working day? midnight? the start of that given working day? You 
would use 'VALUE=DATE' because you want that lower precision, if you 
want to be precise you give a DATE-TIME. We are imposing an unwarranted 
precision....

Regards, Martin

Date: Mon, 19 Feb 2007 11:39:23 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND]

I would like to extend the scope of issue 10 to also cover the handling
of the DUE property when specified as a DATE value in a VTODO component.

The same way that the end time of a VEVENT can be explicitly specified
with the DTEND property or determined with the value of the DURATION
property combined with the value of the DTSTART property, the time at
which a VTODO is expected to be completed can be explicitly specified
with the DUE property or determined with the value of the DURATION
property combined with the value of the DTSTART property.

The same way that the DTEND property specifies the non-inclusive end
of events, the DUE property should be handled the same way for to-dos.

The following are examples of to-dos scheduled to start at 00:00:00 on
February 14, 2007 and expected to be completed before 00:00:00 February
15, 2007. These to-dos have until 23:59:59 on February 14, 2007 to be
completed before they become overdued.

    DTSTART;VALUE=DATE:20070214
    DURATION:P1D

    DTSTART:20070214T000000
    DURATION:P1D

    DTSTART;VALUE=DATE:20070214
    DUE;VALUE=DATE:20070215

    DTSTART:20070214T000000
    DUE:20070215T000000

The following are examples of to-dos scheduled to start at 00:00:00 on
February 14, 2007 and expected to be completed at the exact same time.

    DTSTART;VALUE=DATE:20070214
    DURATION:PT0S

    DTSTART:20070214T000000
    DURATION:PT0S

    DTSTART:20070214T000000
    DUE:20070214T000000

    DTSTART;VALUE=DATE:20070214
    DUE;VALUE=DATE:20070214

The implication here is that any application that presents a DUE property
of DATE value type as a "Due date" needs to substract one day to its value
since for an end user if some to-do is due on Feburary 14, 2007 he has
until the end of the day to complete the to-do (i.e., until 23:59:59 on
February 14, 2007). I've been told that some applications are presenting
this value as "Due by" to avoid this ambiguity.

Cheers,
Bernard

Bernard Desruisseaux wrote:
> I just realized that the 1st issue is already being tracked as issue 10
> in the tracker.
> 
> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10
> 
> Cheers,
> Bernard
> 
> Bernard Desruisseaux wrote:
>> Eliot,
>>
>> There are two issues here:
>>
>> 1- Handling of DTEND for day events;
>> 2- Default duration of day events.
>>
>> The 1st issue was brought up on the list in October 2005 by Chris Stoner:
>>
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000821.html 
>>
>>
>> and I was under the impression that concensus was reached back then.
>> Check Reinhold's replies:
>>
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000823.html 
>>
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000824.html 
>>
>>
>>
>> The 2nd issue was brought up on the list in November 2006 by myself
>> and it is is being tracked as issue 59 in the tracker.
>>
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001341.html 
>>
>> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue59
>>
>> Cheers,
>> Bernard
>>
>> Eliot Lear wrote:
>>> While the issues list for 2445bis is officially closed, since I don't 
>>> see a normative change in the text coming out of this discussion, I 
>>> wouldn't object if someone proposed some example text to make the 
>>> matter clear.  Please copy Bernard and this group directly on any 
>>> such text.
>>>
>>> Eliot

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: George Sexton <[email-masked]>
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART
Date: Fri, 16 Feb 2007 19:46:32 +0100
Cc: [email-masked]

Am Freitag, 16. Februar 2007 schrieb George Sexton:
> > We (KOrganizer) don't have a gui option for it (yet?), but korganizer (or
> > rather libkcal) perfectly understands RDATEs (and EXRULEs, by the way).
> > A quick test indicates that RDATE<DTSTART seems to work, but I cannot
>
> RDATE doesn't work at all in KOrganizer 3.5.5. 

Touch�! Apparently in the method Incidence::doesRecur() we only checked if 
there are any rrules (but forgot to check for rdates, too)... So as long as 
an event has also rrules, the rdates worked.

Actually, our unit tests didn't use doesRecur(), so we didn't find that 
problem so far.

> Look at the entry for the 
> Tanner Gun Show in
>
> webcal://www.mhsoftware.com/caldemo/iCal/calendar_id/8.ics
>
> Is there a version new than 3.5.5 where RDATE does work?

3.5.7 will have the fixes in (I just committed them). Screenshot at
http://www.fam.tuwien.ac.at/~reinhold/KOrganizer/KOrganizer_RDates.jpg
(TZ is Europe/Vienna, which is UTC+1 in winter)

> Additionally, 3.5.5 displays one time events that are in GMT with the
> time in GMT, and not local time.

Another stupid mistake (in korganizer 3.x we didn't support timezones 
properly, but only used the first one for all times if one was present in the 
file; Fixed that now to apply only to non-utc times.).

Cheers,
Reinhold

- -- 

Date: Fri, 16 Feb 2007 10:35:46 -0700
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART
Cc: [email-masked]

Reinhold Kainhofer wrote:
> Am Freitag, 16. Februar 2007 schrieb George Sexton:
>   
>> In a lot of ways, the whole conversation is totally pointless.
>> Evolution, Outlook, KOrganizer, Sunbird, PHPiCalendar, and Apple iCal
>> don't support RDATE events. In short, you're describing a part of the
>> spec that no one (aside from my company) actually implements anyhow...
>>     
>
> We (KOrganizer) don't have a gui option for it (yet?), but korganizer (or 
> rather libkcal) perfectly understands RDATEs (and EXRULEs, by the way).
> A quick test indicates that RDATE<DTSTART seems to work, but I cannot 
>   
RDATE doesn't work at all in KOrganizer 3.5.5. Look at the entry for the 
Tanner Gun Show in

webcal://www.mhsoftware.com/caldemo/iCal/calendar_id/8.ics

Is there a version new than 3.5.5 where RDATE does work?

Additionally, 3.5.5 displays one time events that are in GMT with the 
time in GMT, and not local time.

> guarantee that there are no complications (e.g. implicit assumptions that 
> rdate>=dtstart used somewhere). At least while coding, I was always thinking 
> that dtstart<=rdate. So if it works now, it's simply by coincidence...
>
> Cheers,
> Reinhold
>
> - -- 
> iD8DBQFF1eg2TqjEwhXvPN0RAlK1AKCGUy52PEXheAgTZ5ietz9Btes7KQCgsZh7
> VVCrHFWJKnpZDyskuA834yg=
> =YOSl

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

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <=?iso-8859-1?q?=09DTSTART?=
Date: Fri, 16 Feb 2007 18:21:53 +0100

Am Freitag, 16. Februar 2007 schrieb George Sexton:
> In a lot of ways, the whole conversation is totally pointless.
> Evolution, Outlook, KOrganizer, Sunbird, PHPiCalendar, and Apple iCal
> don't support RDATE events. In short, you're describing a part of the
> spec that no one (aside from my company) actually implements anyhow...

We (KOrganizer) don't have a gui option for it (yet?), but korganizer (or 
rather libkcal) perfectly understands RDATEs (and EXRULEs, by the way).
A quick test indicates that RDATE<DTSTART seems to work, but I cannot 
guarantee that there are no complications (e.g. implicit assumptions that 
rdate>=dtstart used somewhere). At least while coding, I was always thinking 
that dtstart<=rdate. So if it works now, it's simply by coincidence...

Cheers,
Reinhold

- -- 

Date: Fri, 16 Feb 2007 09:42:58 -0700
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: ietf-calsify <[email-masked]>
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <	DTSTART

Silly me.

I keep thinking the standard should be written in such a way as to make 
a correct implementation simpler and more likely to happen. Instead, 
this standard is all about pedantically describing a whole universe of 
silly, possible cases. This is a perfect example. There's no GOOD reason 
to allow this. It adds no functionality, but instead adds useless 
complication. Instead of explicitly codifying what' wasn't explicitly 
said before, this should be explicitly forbidden because it adds no 
functionality, only complexity.

In a lot of ways, the whole conversation is totally pointless. 
Evolution, Outlook, KOrganizer, Sunbird, PHPiCalendar, and Apple iCal 
don't support RDATE events. In short, you're describing a part of the 
spec that no one (aside from my company) actually implements anyhow...

As far as your comments about my test case go, my test case was meant to 
demonstrate a optimization that a developer would likely to be come up 
with. Having an EXDATE the same as DTSTART would not have actually 
broken my test case. The item with an EXDATE would have remained in the 
set of candidate items, where it would have had the expensive tests 
done, but it would not have been eliminated from the candidate set. This 
EXDATE/DTSTART is another stupid case. Who thinks this stuff up? Has 
anyone here besides me actually written a calendar that was good enough 
other people would pay money for it?

In regards to your comments about DTEND not representing the last 
element in the set. You're right. Personally, I think the whole idea of 
determining the duration for recurring event from the DTEND was a stupid 
idea. Using DURATION would have been much simpler, and using DTEND 
brings in all sorts of wormy problems of dealing with DST transitions. 
It should never have been done.

I've always believed that the real goal of RFC-2445 was to make the 
standard so complex that it would never be possible to have applications 
that could share data. It's reassuring to see that this isn't changing.

Cyrus Daboo wrote:
> Hi George,
>
> --On February 15, 2007 2:53:14 PM -0700 George Sexton 
> <[email-masked]> wrote:
>
>> I think that having a field labeled DTSTART, which is not actually the
>> first occurrence of a set is a bad idea.
>
> Just as DTEND does not represent the end of the last occurrence in the 
> set?
>
>> It actually doesn't break any of my code, but I still think it's a bad
>> idea.
>>
>> Take a candidate item:
>>
>> DTSTART:20070205
>> RDATE:20070120,20070127,20070228
>>
>> I could see someone else writing some code that goes along these lines:
>>
>> - Display a calendar for January 2007
>> - Step 1 - Get the candidate set of items
>> - Step 2 - Eliminate all candidate items that have a DTSTART after 31
>> January 2007. Then, we can avoid all of the really expensive and compute
>> intensive items that we know don't occur.
>> - Step 3 - Your clever, poorly written entry just got bounced.
>
> It is a trivial matter to include tests on any RDATEs in that 
> procedure. Maybe it is worth putting a note in 2445bis's DTSTART 
> section explaining that the DTSTART may not represent the first 
> instance start in the instance set, and that RDATE should be checked 
> if present.
>
> But ultimately it is an implementation issue - anyone using a database 
> or index to handle instance sets will likely not care as they may have 
> expanded the set out already and will do time-range queries using that 
> data. Anyone manipulating iCalendar data directly in their database 
> will need to pay attention to this.
>
>> This a bad idea and should be ditched.
>>
>> There's no justifiable benefit. Some developer can get a little sloppier
>> writing his file. In the meantime every potential consumer has to look
>> out for it.
>
> You already have to look out for it - the original 2445 never 
> expressly ruled out RDATE < DTSTART. Also, it allows EXDATE == 
> DTSTART, which means that DTSTART would no longer represent the first 
> instance start time. That would result in a false positive following 
> your steps 1-3 above.
>
> Either way 2445bis is being more explicit about this so that everyone 
> is aware of what can possibly happen.
>

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

Date: Fri, 16 Feb 2007 10:12:30 -0500
From: Cyrus Daboo <[email-masked]>
To: George Sexton <[email-masked]>, [email-masked]
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times:	RDATE <	DTSTART

Hi George,

--On February 15, 2007 2:53:14 PM -0700 George Sexton 
<[email-masked]> wrote:

> I think that having a field labeled DTSTART, which is not actually the
> first occurrence of a set is a bad idea.

Just as DTEND does not represent the end of the last occurrence in the set?

> It actually doesn't break any of my code, but I still think it's a bad
> idea.
>
> Take a candidate item:
>
> DTSTART:20070205
> RDATE:20070120,20070127,20070228
>
> I could see someone else writing some code that goes along these lines:
>
> - Display a calendar for January 2007
> - Step 1 - Get the candidate set of items
> - Step 2 - Eliminate all candidate items that have a DTSTART after 31
> January 2007. Then, we can avoid all of the really expensive and compute
> intensive items that we know don't occur.
> - Step 3 - Your clever, poorly written entry just got bounced.

It is a trivial matter to include tests on any RDATEs in that procedure. 
Maybe it is worth putting a note in 2445bis's DTSTART section explaining 
that the DTSTART may not represent the first instance start in the instance 
set, and that RDATE should be checked if present.

But ultimately it is an implementation issue - anyone using a database or 
index to handle instance sets will likely not care as they may have 
expanded the set out already and will do time-range queries using that 
data. Anyone manipulating iCalendar data directly in their database will 
need to pay attention to this.

> This a bad idea and should be ditched.
>
> There's no justifiable benefit. Some developer can get a little sloppier
> writing his file. In the meantime every potential consumer has to look
> out for it.

You already have to look out for it - the original 2445 never expressly 
ruled out RDATE < DTSTART. Also, it allows EXDATE == DTSTART, which means 
that DTSTART would no longer represent the first instance start time. That 
would result in a false positive following your steps 1-3 above.

Either way 2445bis is being more explicit about this so that everyone is 
aware of what can possibly happen.

-- 
Cyrus Daboo

Date: Thu, 15 Feb 2007 20:41:05 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance?
Cc: [email-masked]

Hi Reinhold,

Reinhold Kainhofer wrote:
> Am Donnerstag, 15. Februar 2007 schrieb Bernard Desruisseaux:
>> In section 4.6.5 Time Zone Component of RFC 2445 it says:
>>  > If specified, the onset for the observance defined by the time zone
>>  > sub-component is defined by either the "RRULE" or "RDATE" property.
>>
>> If the sub-component specifies "RDATE" properties and no "RRULE"
>> property, is the "DTSTART" property still considered as a onset
>> date-time?  I would sure hope so.
> 
> Actually, I don't think so. The DTSTART is the date when the whole DST 
> definition comes into effect. E.g. when the EU harmonized the DST 
> regulations, that date would be the DTSTART, but the first onset of DAYLIGHT  
> is actually later.

You are mistaken.

Here's from section 4.6.5 of RFC 2445:

   The mandatory "DTSTART" property gives the effective onset date and
   local time for the time zone sub-component definition.

and also:

   "TZOFFSETFROM" is combined with "DTSTART" to define the effective
   onset for the time zone sub-component definition.

and then later:

    - The "DTSTART" and the "TZOFFSETTO" properties MUST be used
    when generating the onset date-time values (instances) from the
    RRULE.

> Compare this also with the example given in section "4.6.5 
> Time Zone Component" of rfc 2445:
>      BEGIN:DAYLIGHT
>      DTSTART:19971026T020000
>      RDATE:19970406T020000
>      TZOFFSETFROM:-0500
>      TZOFFSETTO:-0400
>      TZNAME:EDT
>      END:DAYLIGHT
> 
> Here, oct 26, 1997 is the date when the whole DST regulation came into effect, 
> but the first DST occurred already a few months earlier (????).

The example you are quoting contains a mistake. The DTSTART specified
in the DAYLIGHT sub-component is actually a copy'n'paste of the DTSTART
specified in the STANDARD sub-component. The DTSTART in the DAYLIGHT
sub-component was supposed to be set to 19970406T02000, that is, the
same value as RDATE. This has been fixed since draft -01 of rfc2445bis.

>> The "STANDARD" and "DAYLIGHT" examples in the draft always duplicate
>> the value of "DTSTART" in a "RDATE" property. Which I think should be
>> superfluous.  I noticed that the the "VTIMEZONE" generated by "vzic"
>> always duplicate the value of "DTSTART" in a "RDATE" property, but
>> I was also able to find "VTIMEZONE" examples on the Internet which
>> do not.
> 
> Hehe, a simple look at RFC 2445 would have gotten you one ;-)

Right, but only because it is erroneous as mentionned above.

> 
>> I propose we clarify that DTSTART always specify a onset date-time
>> of an observance.
> 
> I would rather clarify that DTSTART does NOT specify an onset date, but rather 
> the date when the regulation came into effect. Thus, there are typically a 
> DAYLIGHT and a STANDARD with the same DTSTART.

No.

> 
>> Then, in the same paragraph the text goes one with:
>>  > If neither is specified, only one sub-component can be specified in
>>  > the "VTIMEZONE" calendar component and it is assumed that the single
>>  > observance specified is always in effect.
>>
>> If I understand this correctly, if a "VTIMEZONE" component defines
>> a "STANDARD" or "DAYLIGHT" sub-component with only the "DTSTART"
>> property, than it ?must? (requirement level not clear) be the only
>> sub-component defined in the "VTIMEZONE" component. I have no clue
>> why there is such a restriction.
> 
> Because the DTSTART does not introduce an onset date, so that component has to 
> be defined to either not take effect at any time or forever...

No.

> 
>> Again, I was able to find "VTIMEZONE" examples that specify both
>> "STANDARD" and "DAYLIGHT" sub-components with each only the
>> "DTSTART" property.
>>
>> I propose that we remove this restriction.
> 
> We should at least clarify it. RFC 2445 clearly means that the DTSTART does 
> not define an onset date.

Can you please specify which part of RFC 2445 brought you to believe
all of this?

Thanks,
Bernard

> If implementations out there do it differently, 
> we'll have to clarify that.
> 
> Cheers,
> Reinhold
> - -- 
> Version: GnuPG v1.4.3 (GNU/Linux)
> 
> iD8DBQFF1OA8TqjEwhXvPN0RAmfvAKCLY1n1ho8M1DlZ42iAGI1Nuf9AnwCgp0J5
> cenbhO/IL3ap3qTgT1VhfjQ=
> =PVE8

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance?
Date: Thu, 15 Feb 2007 23:35:38 +0100

Am Donnerstag, 15. Februar 2007 schrieb Bernard Desruisseaux:
> In section 4.6.5 Time Zone Component of RFC 2445 it says:
>  > If specified, the onset for the observance defined by the time zone
>  > sub-component is defined by either the "RRULE" or "RDATE" property.
>
> If the sub-component specifies "RDATE" properties and no "RRULE"
> property, is the "DTSTART" property still considered as a onset
> date-time?  I would sure hope so.

Actually, I don't think so. The DTSTART is the date when the whole DST 
definition comes into effect. E.g. when the EU harmonized the DST 
regulations, that date would be the DTSTART, but the first onset of DAYLIGHT  
is actually later. Compare this also with the example given in section "4.6.5 
Time Zone Component" of rfc 2445:
     BEGIN:DAYLIGHT
     DTSTART:19971026T020000
     RDATE:19970406T020000
     TZOFFSETFROM:-0500
     TZOFFSETTO:-0400
     TZNAME:EDT
     END:DAYLIGHT

Here, oct 26, 1997 is the date when the whole DST regulation came into effect, 
but the first DST occurred already a few months earlier (????).

> The "STANDARD" and "DAYLIGHT" examples in the draft always duplicate
> the value of "DTSTART" in a "RDATE" property. Which I think should be
> superfluous.  I noticed that the the "VTIMEZONE" generated by "vzic"
> always duplicate the value of "DTSTART" in a "RDATE" property, but
> I was also able to find "VTIMEZONE" examples on the Internet which
> do not.

Hehe, a simple look at RFC 2445 would have gotten you one ;-)

> I propose we clarify that DTSTART always specify a onset date-time
> of an observance.

I would rather clarify that DTSTART does NOT specify an onset date, but rather 
the date when the regulation came into effect. Thus, there are typically a 
DAYLIGHT and a STANDARD with the same DTSTART.

> Then, in the same paragraph the text goes one with:
>  > If neither is specified, only one sub-component can be specified in
>  > the "VTIMEZONE" calendar component and it is assumed that the single
>  > observance specified is always in effect.
>
> If I understand this correctly, if a "VTIMEZONE" component defines
> a "STANDARD" or "DAYLIGHT" sub-component with only the "DTSTART"
> property, than it ?must? (requirement level not clear) be the only
> sub-component defined in the "VTIMEZONE" component. I have no clue
> why there is such a restriction.

Because the DTSTART does not introduce an onset date, so that component has to 
be defined to either not take effect at any time or forever...

> Again, I was able to find "VTIMEZONE" examples that specify both
> "STANDARD" and "DAYLIGHT" sub-components with each only the
> "DTSTART" property.
>
> I propose that we remove this restriction.

We should at least clarify it. RFC 2445 clearly means that the DTSTART does 
not define an onset date. If implementations out there do it differently, 
we'll have to clarify that.

Cheers,
Reinhold
- -- 

Date: Thu, 15 Feb 2007 14:53:14 -0700
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: [email-masked]
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <	DTSTART

Foolish consistency is the hob-goblin of small minds.

I guess I'm small minded.

I think that having a field labeled DTSTART, which is not actually the 
first occurrence of a set is a bad idea.

It actually doesn't break any of my code, but I still think it's a bad idea.

Take a candidate item:

DTSTART:20070205
RDATE:20070120,20070127,20070228

I could see someone else writing some code that goes along these lines:

- Display a calendar for January 2007
- Step 1 - Get the candidate set of items
- Step 2 - Eliminate all candidate items that have a DTSTART after 31 
January 2007. Then, we can avoid all of the really expensive and compute 
intensive items that we know don't occur.
- Step 3 - Your clever, poorly written entry just got bounced.

This a bad idea and should be ditched.

There's no justifiable benefit. Some developer can get a little sloppier 
writing his file. In the meantime every potential consumer has to look 
out for it.

Bernard Desruisseaux wrote:
> Hi George,
>
> "DTSTART" specifies the start date and time of a single recurrence
> instance. In a recurring component, this recurrence instance is
> always the first instance generated by the "RRULE". I don't see
> any reason to restrict this recurrence instance to be the first
> instance of the entire recurrence set.
>
> What exactly does it mean to be the first instance? To be the
> first instance to occur based on its original start time (i.e.,
> "RECURRENCE-ID") or to be the first instance to occur based on
> its effective start time?  Does it really matter?
>
> One can reschedule any recurrence instance earlier in time than
> the recurrence instance defined by "DTSTART". I see no reason to
> prevent one from defining an additional recurrence instance with
> an original start time earlier in time than "DTSTART".
>
> Cheers,
> Bernard
>
> George Sexton wrote:
>> What sort of intoxicants are served at these meetings?
>>
>> How in the universe does this make sense?
>>
>> The DTSTART is not really the DTSTART?
>>
>> Are there other instances or cases when DTSTART is not DTSTART?
>>
>> Bernard Desruisseaux wrote:
>>> At the Jabber session held on February 8, 2007 we had consensus to
>>> modify the draft to clarify that "RDATE" can specify a value earlier
>>> in time than "DTSTART" in "VEVENT", "VTODO" and "VJOURNAL" calendar
>>> components but more discussion was deemed necessary for "VTIMEZONE".
>>>
>>> I'm not aware of any restriction in RFC 2445 that would prevent one
>>> to specify an "RDATE" property that specifies a value earlier in time
>>> than the "DTSTART" property in a "VTIMEZONE" component.
>>>
>>> To find the offset to apply to a given time one needs to determine
>>> the observance that has the last onset date and time before the
>>> time in question, and use the offset value from that observance.
>>> All sub-components should be taken into account when doing so.
>>>
>>> Speak up if you have any concerns to apply the clarification to
>>> "VTIMEZONE" components as well.
>>>
>>> Cheers,
>>> Bernard
>>>
>>>
>>> Eliot Lear wrote:
>>>> I would like to know if there are objections to this Issue being 
>>>> accepted and the text being included, subject to clarifying text 
>>>> about VTIMEZONE.
>>>>
>>>> Thanks,
>>>>
>>>> Eliot
>>>>
>>>> Bernard Desruisseaux wrote:
>>>>> Reinhold,
>>>>>
>>>>> In my opinion we need to allow RDATE to be less than DTSTART,
>>>>> even more so now that DTSTART should be synchronized with the
>>>>> recurrence rule.
>>>>>
>>>>> Let's say I want to have a meeting today (Monday) with three
>>>>> further instances on the next upcoming Tuesday. I could easily
>>>>> do that with an RDATE set to today (Monday) and a DTSTART set
>>>>> to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.
>>>>>
>>>>> Cheers,
>>>>> Bernard
>>>>>
>>>>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
>>>>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>>>>>>>  > The "DTSTART" property defines the first instance in the
>>>>>>>  > recurrence set.
>>>>>>>
>>>>>>> I believe this section should clarify that the "RDATE" property
>>>>>>> value can actually be earlier in time than the value of the
>>>>>>> "DTSTART" property.
>>>>>>
>>>>>> I always understood this sentence that the DTSTART is always the 
>>>>>> first date/time of the event and RDATE cannot be earlier. 
>>>>>> Otherwise, to determine whether an event happens today, one would 
>>>>>> have to look at all recurrences of all events, future or past. If 
>>>>>> the DTSTART is always the first time, then it suffices to look at 
>>>>>> all events that have already started at the given date (i.e. 
>>>>>> DTSTART<=givenDateTime).
>>>>>>
>>>>>> Cheers,
>>>>>> Reinhold
>>>>>> - -- - 
>>>>>> ------------------------------------------------------------------
>>>>>> Version: GnuPG v1.4.3 (GNU/Linux)
>>>>>>
>>>>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6
>>>>>> RUXtgVx4DX3mzyaAq+CT9j4=
>>>>>> =5sgz

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

Date: Thu, 15 Feb 2007 16:42:31 -0500
From: Bernard Desruisseaux <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <	DTSTART
Cc: [email-masked]

Hi George,

"DTSTART" specifies the start date and time of a single recurrence
instance. In a recurring component, this recurrence instance is
always the first instance generated by the "RRULE". I don't see
any reason to restrict this recurrence instance to be the first
instance of the entire recurrence set.

What exactly does it mean to be the first instance? To be the
first instance to occur based on its original start time (i.e.,
"RECURRENCE-ID") or to be the first instance to occur based on
its effective start time?  Does it really matter?

One can reschedule any recurrence instance earlier in time than
the recurrence instance defined by "DTSTART". I see no reason to
prevent one from defining an additional recurrence instance with
an original start time earlier in time than "DTSTART".

Cheers,
Bernard

George Sexton wrote:
> What sort of intoxicants are served at these meetings?
> 
> How in the universe does this make sense?
> 
> The DTSTART is not really the DTSTART?
> 
> Are there other instances or cases when DTSTART is not DTSTART?
> 
> Bernard Desruisseaux wrote:
>> At the Jabber session held on February 8, 2007 we had consensus to
>> modify the draft to clarify that "RDATE" can specify a value earlier
>> in time than "DTSTART" in "VEVENT", "VTODO" and "VJOURNAL" calendar
>> components but more discussion was deemed necessary for "VTIMEZONE".
>>
>> I'm not aware of any restriction in RFC 2445 that would prevent one
>> to specify an "RDATE" property that specifies a value earlier in time
>> than the "DTSTART" property in a "VTIMEZONE" component.
>>
>> To find the offset to apply to a given time one needs to determine
>> the observance that has the last onset date and time before the
>> time in question, and use the offset value from that observance.
>> All sub-components should be taken into account when doing so.
>>
>> Speak up if you have any concerns to apply the clarification to
>> "VTIMEZONE" components as well.
>>
>> Cheers,
>> Bernard
>>
>>
>> Eliot Lear wrote:
>>> I would like to know if there are objections to this Issue being 
>>> accepted and the text being included, subject to clarifying text 
>>> about VTIMEZONE.
>>>
>>> Thanks,
>>>
>>> Eliot
>>>
>>> Bernard Desruisseaux wrote:
>>>> Reinhold,
>>>>
>>>> In my opinion we need to allow RDATE to be less than DTSTART,
>>>> even more so now that DTSTART should be synchronized with the
>>>> recurrence rule.
>>>>
>>>> Let's say I want to have a meeting today (Monday) with three
>>>> further instances on the next upcoming Tuesday. I could easily
>>>> do that with an RDATE set to today (Monday) and a DTSTART set
>>>> to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.
>>>>
>>>> Cheers,
>>>> Bernard
>>>>
>>>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
>>>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>>>>>>  > The "DTSTART" property defines the first instance in the
>>>>>>  > recurrence set.
>>>>>>
>>>>>> I believe this section should clarify that the "RDATE" property
>>>>>> value can actually be earlier in time than the value of the
>>>>>> "DTSTART" property.
>>>>>
>>>>> I always understood this sentence that the DTSTART is always the 
>>>>> first date/time of the event and RDATE cannot be earlier. 
>>>>> Otherwise, to determine whether an event happens today, one would 
>>>>> have to look at all recurrences of all events, future or past. If 
>>>>> the DTSTART is always the first time, then it suffices to look at 
>>>>> all events that have already started at the given date (i.e. 
>>>>> DTSTART<=givenDateTime).
>>>>>
>>>>> Cheers,
>>>>> Reinhold
>>>>> - -- - 
>>>>> ------------------------------------------------------------------
>>>>> Version: GnuPG v1.4.3 (GNU/Linux)
>>>>>
>>>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6
>>>>> RUXtgVx4DX3mzyaAq+CT9j4=
>>>>> =5sgz

Date: Thu, 15 Feb 2007 13:13:15 -0800
From: Jeffrey Harris <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Exchange and new timezones

Hi Folks,

I thought I'd mention to other folks an issue with the way
Exchange/Outlook are dealing with the new US timezones.

Here's the VTIMEZONE Outlook serialized for a US/Eastern recurring event
starting in mid-2006:

BEGIN:VTIMEZONE
TZID:GMT -0500 (Standard) / GMT -0400 (Daylight)
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
END:VTIMEZONE

Microsoft has chosen to treat the new US daylight savings time
transitions as if they begin in 1601, 147 years before Ben Franklin
first mentioned the idea of DST publicly, 406 years before the new
timezones actually go into effect.

Chandler maps timezones into Olson timezones based on the DST
transitions near the start of the event.  Since this event started in
2006, we didn't find an appropriate timezone.  I believe iCal may have
the same problem.  Beware if you'd like to interop with Outlook.

Sincerely,
Jeffrey

Date: Thu, 15 Feb 2007 16:10:13 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance?

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

 > If specified, the onset for the observance defined by the time zone
 > sub-component is defined by either the "RRULE" or "RDATE" property.

If the sub-component specifies "RDATE" properties and no "RRULE"
property, is the "DTSTART" property still considered as a onset
date-time?  I would sure hope so.

The "STANDARD" and "DAYLIGHT" examples in the draft always duplicate
the value of "DTSTART" in a "RDATE" property. Which I think should be
superfluous.  I noticed that the the "VTIMEZONE" generated by "vzic"
always duplicate the value of "DTSTART" in a "RDATE" property, but
I was also able to find "VTIMEZONE" examples on the Internet which
do not.

I propose we clarify that DTSTART always specify a onset date-time
of an observance.

Then, in the same paragraph the text goes one with:

 > If neither is specified, only one sub-component can be specified in
 > the "VTIMEZONE" calendar component and it is assumed that the single
 > observance specified is always in effect.

If I understand this correctly, if a "VTIMEZONE" component defines
a "STANDARD" or "DAYLIGHT" sub-component with only the "DTSTART"
property, than it ?must? (requirement level not clear) be the only
sub-component defined in the "VTIMEZONE" component. I have no clue
why there is such a restriction.

Again, I was able to find "VTIMEZONE" examples that specify both
"STANDARD" and "DAYLIGHT" sub-components with each only the
"DTSTART" property.

I propose that we remove this restriction.

Cheers,
Bernard

Date: Thu, 15 Feb 2007 14:05:24 -0700
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <	DTSTART
Cc: [email-masked]

What sort of intoxicants are served at these meetings?

How in the universe does this make sense?

The DTSTART is not really the DTSTART?

Are there other instances or cases when DTSTART is not DTSTART?

Bernard Desruisseaux wrote:
> At the Jabber session held on February 8, 2007 we had consensus to
> modify the draft to clarify that "RDATE" can specify a value earlier
> in time than "DTSTART" in "VEVENT", "VTODO" and "VJOURNAL" calendar
> components but more discussion was deemed necessary for "VTIMEZONE".
>
> I'm not aware of any restriction in RFC 2445 that would prevent one
> to specify an "RDATE" property that specifies a value earlier in time
> than the "DTSTART" property in a "VTIMEZONE" component.
>
> To find the offset to apply to a given time one needs to determine
> the observance that has the last onset date and time before the
> time in question, and use the offset value from that observance.
> All sub-components should be taken into account when doing so.
>
> Speak up if you have any concerns to apply the clarification to
> "VTIMEZONE" components as well.
>
> Cheers,
> Bernard
>
>
> Eliot Lear wrote:
>> I would like to know if there are objections to this Issue being 
>> accepted and the text being included, subject to clarifying text 
>> about VTIMEZONE.
>>
>> Thanks,
>>
>> Eliot
>>
>> Bernard Desruisseaux wrote:
>>> Reinhold,
>>>
>>> In my opinion we need to allow RDATE to be less than DTSTART,
>>> even more so now that DTSTART should be synchronized with the
>>> recurrence rule.
>>>
>>> Let's say I want to have a meeting today (Monday) with three
>>> further instances on the next upcoming Tuesday. I could easily
>>> do that with an RDATE set to today (Monday) and a DTSTART set
>>> to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.
>>>
>>> Cheers,
>>> Bernard
>>>
>>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
>>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>>>>>  > The "DTSTART" property defines the first instance in the
>>>>>  > recurrence set.
>>>>>
>>>>> I believe this section should clarify that the "RDATE" property
>>>>> value can actually be earlier in time than the value of the
>>>>> "DTSTART" property.
>>>>
>>>> I always understood this sentence that the DTSTART is always the 
>>>> first date/time of the event and RDATE cannot be earlier. 
>>>> Otherwise, to determine whether an event happens today, one would 
>>>> have to look at all recurrences of all events, future or past. If 
>>>> the DTSTART is always the first time, then it suffices to look at 
>>>> all events that have already started at the given date (i.e. 
>>>> DTSTART<=givenDateTime).
>>>>
>>>> Cheers,
>>>> Reinhold
>>>> - -- - 
>>>> ------------------------------------------------------------------
>>>> Version: GnuPG v1.4.3 (GNU/Linux)
>>>>
>>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6
>>>> RUXtgVx4DX3mzyaAq+CT9j4=
>>>> =5sgz

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

Date: Thu, 15 Feb 2007 15:53:31 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM

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

 > The mandatory "TZOFFSETFROM" property gives the UTC offset which
 > is in use when the onset of this time zone observance begins.
 > "TZOFFSETFROM" is combined with "DTSTART" to define the effective
 > onset for the time zone sub-component definition.  For example,
 > the following represents the time at which the observance of
 > Standard Time took effect in Fall 1967 for New York City:
 >
 >   DTSTART:19671029T020000
 >
 >   TZOFFSETFROM:-0400

But later in the same section it says:

 >     - The "DTSTART" and the "TZOFFSETTO" properties MUST be used
 >     when generating the onset date-time values (instances) from the
 >     RRULE.

Clearly, this last paragraph should say "TZOFFSETFROM" instead of
"TZOFFSETTO".

Proposed new text:

 >     - The "DTSTART" and the "TZOFFSETFROM" properties MUST be used
 >     when generating the onset date-time values (instances) from the
 >     RRULE.

Cheers,
Bernard

Date: Thu, 15 Feb 2007 15:51:49 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <	DTSTART

At the Jabber session held on February 8, 2007 we had consensus to
modify the draft to clarify that "RDATE" can specify a value earlier
in time than "DTSTART" in "VEVENT", "VTODO" and "VJOURNAL" calendar
components but more discussion was deemed necessary for "VTIMEZONE".

I'm not aware of any restriction in RFC 2445 that would prevent one
to specify an "RDATE" property that specifies a value earlier in time
than the "DTSTART" property in a "VTIMEZONE" component.

To find the offset to apply to a given time one needs to determine
the observance that has the last onset date and time before the
time in question, and use the offset value from that observance.
All sub-components should be taken into account when doing so.

Speak up if you have any concerns to apply the clarification to
"VTIMEZONE" components as well.

Cheers,
Bernard

Eliot Lear wrote:
> I would like to know if there are objections to this Issue being 
> accepted and the text being included, subject to clarifying text about 
> VTIMEZONE.
> 
> Thanks,
> 
> Eliot
> 
> Bernard Desruisseaux wrote:
>> Reinhold,
>>
>> In my opinion we need to allow RDATE to be less than DTSTART,
>> even more so now that DTSTART should be synchronized with the
>> recurrence rule.
>>
>> Let's say I want to have a meeting today (Monday) with three
>> further instances on the next upcoming Tuesday. I could easily
>> do that with an RDATE set to today (Monday) and a DTSTART set
>> to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.
>>
>> Cheers,
>> Bernard
>>
>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>>>>  > The "DTSTART" property defines the first instance in the
>>>>  > recurrence set.
>>>>
>>>> I believe this section should clarify that the "RDATE" property
>>>> value can actually be earlier in time than the value of the
>>>> "DTSTART" property.
>>>
>>> I always understood this sentence that the DTSTART is always the 
>>> first date/time of the event and RDATE cannot be earlier. Otherwise, 
>>> to determine whether an event happens today, one would have to look 
>>> at all recurrences of all events, future or past. If the DTSTART is 
>>> always the first time, then it suffices to look at all events that 
>>> have already started at the given date (i.e. DTSTART<=givenDateTime).
>>>
>>> Cheers,
>>> Reinhold
>>> - -- - 
>>> ------------------------------------------------------------------
>>> Version: GnuPG v1.4.3 (GNU/Linux)
>>>
>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6
>>> RUXtgVx4DX3mzyaAq+CT9j4=
>>> =5sgz

Date: Thu, 15 Feb 2007 06:55:18 -0800
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts in 5 minutes!

See you there!

Date: Tue, 13 Feb 2007 11:23:40 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Re: [Fwd: 2445bis: clarify allowed value types of date-time property combinations]

Hi Bernard,

--On February 13, 2007 11:13:03 AM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> [
>    Dear chairs, please add the issues that Cyrus previously raised on the
>    list to the tracker.
>
>
> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-July/001012.ht
> ml
> ]
>
>  > -------- Original Message --------
>  > Subject: 2445bis: clarify allowed value types of date-time property
> combinations
>  > Date: Fri, 21 Jul 2006 12:00:48 -0400
>  > From: Cyrus Daboo <[email-masked]>
>  > To: Bernard Desruisseaux <[email-masked]>
>  > CC: [email-masked]
>  >
>  > Hi Bernard,
>  > I was just checking on the behavior for the VALUE type of DTSTART/DTEND
>  > and DTSTART/DUE in VEVENT and VTODO. Right now for VEVENT, the only
>  > restriction I see is that if DTSTART is a DATE then DTEND must also be
> a
>  > DATE. That means that having DTSTART be DATE-TIME and DTEND be DATE is
>  > allowed (provided DTEND is later than DTSTART). If that is allowed then
>  > I would like to see it explicitly stated - perhaps a table of the two
>  > properties with yes/no for combinations of value types?
>
> I propose to change the following text from section 4.8.2.2
> Date/Time End of RFC 2445:
>
>    Description: Within the "VEVENT" calendar component, this property
>    defines the date and time by which the event ends. The value MUST be
>    later in time than the value of the "DTSTART" property.
>
> as follows:
>
>    Description: Within the "VEVENT" calendar component, this property
>    defines the date and time by which the event ends.  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.
>
>  > The issue with VTODO is more complex as there is no restriction at all,
>  > so DTSTART as DATE and DUE as DATE-TIME, or DTSTART as DATE-TIME and
> DUE
>  > as DATE is allowed. I was just bitten by this so would like to see more
>  > clarification as per VEVENT.
>
> I propose to change the following text from section 4.8.2.3 Date/Time Due
> of RFC 2445:
>
>    Description: The value MUST be a date/time equal to or after the
>    DTSTART value, if specified.
>
> as follows:
>
>    Description: This property defines the date and time that a to-do is
>    expected to be completed.  For cases where this property is specified
>    in a "VTODO" component that also specifies a "DTSTART" property, 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.

+1 for these.

-- 
Cyrus Daboo

Date: Tue, 13 Feb 2007 11:13:03 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] [Fwd: 2445bis: clarify allowed value types of date-time property combinations]

[
   Dear chairs, please add the issues that Cyrus previously raised on the
   list to the tracker.

   http://lists.osafoundation.org/pipermail/ietf-calsify/2006-July/001012.html
]

 > -------- Original Message --------
 > Subject: 2445bis: clarify allowed value types of date-time property combinations
 > Date: Fri, 21 Jul 2006 12:00:48 -0400
 > From: Cyrus Daboo <[email-masked]>
 > To: Bernard Desruisseaux <[email-masked]>
 > CC: [email-masked]
 >
 > Hi Bernard,
 > I was just checking on the behavior for the VALUE type of DTSTART/DTEND
 > and DTSTART/DUE in VEVENT and VTODO. Right now for VEVENT, the only
 > restriction I see is that if DTSTART is a DATE then DTEND must also be a
 > DATE. That means that having DTSTART be DATE-TIME and DTEND be DATE is
 > allowed (provided DTEND is later than DTSTART). If that is allowed then
 > I would like to see it explicitly stated - perhaps a table of the two
 > properties with yes/no for combinations of value types?

I propose to change the following text from section 4.8.2.2
Date/Time End of RFC 2445:

   Description: Within the "VEVENT" calendar component, this property
   defines the date and time by which the event ends. The value MUST be
   later in time than the value of the "DTSTART" property.

as follows:

   Description: Within the "VEVENT" calendar component, this property
   defines the date and time by which the event ends.  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.

 > The issue with VTODO is more complex as there is no restriction at all,
 > so DTSTART as DATE and DUE as DATE-TIME, or DTSTART as DATE-TIME and DUE
 > as DATE is allowed. I was just bitten by this so would like to see more
 > clarification as per VEVENT.

I propose to change the following text from section 4.8.2.3 Date/Time Due
of RFC 2445:

   Description: The value MUST be a date/time equal to or after the
   DTSTART value, if specified.

as follows:

   Description: This property defines the date and time that a to-do is
   expected to be completed.  For cases where this property is specified
   in a "VTODO" component that also specifies a "DTSTART" property, 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.

 > PS This might tie in with the UNTIL value issue too. Perhaps a table of
 > all date/time related properties for each component with an indication
 > of what combinations of values each is allowed would be good.

This one is already in the tracker as issue 23.  Draft -06 will state
the following:

   The value of the UNTIL rule part MUST have the same value type as the
   "DTSTART" property.

Cheers,
Bernard

Date: Mon, 12 Feb 2007 12:37:21 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]
Reply-To: [email-masked]

On 12/02/07, Nigel Swinson <[email-masked]> wrote:
> > I agree that's easier but this is a recurrence rule used for certain
> > business rules that is expressible today, but not if the proposed
> > change goes into effect.
> >
> > See http://www.google.com/search?q=15th+and+30th+of+the+month for
> > examples of where this rule is described.  It seems to be mostly used
> > as a way of expressing a bi-monthly deadline for receipt of forms.
>
> Ok, interesting, but I still think it's a corner case that even if the standard supports, it is very unlikely that any gui will.  Even then if we are talking about businesses, then they work with working days rather than calendar days, so if the 30th or the 15th land on a weekend, then what they really mean is the next business day that lands after the 15th or the 30th, your rule doesn't catch that.

Nigel,

Yes, I agree that this is probably marginal but corner case is in the
eyes of the beholder and some business rules really are independent of
weekdays -- shipments are shipped and deliveries delivered based on
when things spoil which is independent of weekday.

And most business rules are adjusted based on ^(weekends U holidays).

That said, if you're going to ask for an example that doesn't use
BYDAY it seems perverse to reject examples because they don't filter
by day.

Very few calendar UIs allow creation of RRULEs with BYSETPOS, and most
uses of BYSETPOS that I've seen have been holidays and business rules
where the maintainer has some level of technical expertise.

>
> Here are other ways I think the rule is more usefully expressed:
>
> RRULE:FREQ=MONTHLY;BYMONTHDAY=-1,15

> RRULE:FREQ=DAILY;INTERVAL=15
>
> RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=11,-1
>
> RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1,12
>
> RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30
> RDATE;VALUE=DATE:20070228,20080229,20090228,20090229,20100228

>
> Even a google for BYSETPOS only returns 805 entries, so it can hardly be a commonly used part of the standard.  Compare that to BYMONTH which has 240,000 hits.

In this case I think you're right, but be very skeptical of comparing
hit counts http://www.searchengineshowdown.com/features/google/inconsistent.shtml#count

> I'd be interested in hearing any other opinions on the proposal?
>
> Nigel
>

Date: Mon, 12 Feb 2007 12:19:27 -0800
From: "Mike Samuel" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]
Reply-To: [email-masked]

On 12/02/07, Cyrus Daboo <[email-masked]> wrote:
> Hi Mike,
>
> --On February 12, 2007 9:55:46 AM -0800 Mike Samuel <[email-masked]>
> wrote:
>
> > I agree that's easier but this is a recurrence rule used for certain
> > business rules that is expressible today, but not if the proposed
> > change goes into effect.
> >
> > See http://www.google.com/search?q=15th+and+30th+of+the+month for
> > examples of where this rule is described.  It seems to be mostly used
> > as a way of expressing a bi-monthly deadline for receipt of forms.
>
> Remember that there are always going to be rules that are hard or
> impossible to rally get to work with RRULE. Taking your example: what
> happens if the 15th or 30th is a weekend - one might expect the forms to
> come in the Friday before or perhaps the Monday after - then how do you use
> RRULE (remember only a single RRULE is now allowed in 2445bis)?

I realize that.  The question was whether there were any examples that
were supportable now that would not be if the proposal were adopted
and that was the question I answered.

> The fallback of course is to use a finite set of RDATEs that get "renewed"
> periodically as needed. That fallback could be used if Nigel's proposal
> were to be adopted.

This would be wonderful for supporting holidays and birthdays
calculated according to a lunar/lunisolar calendar.

> I'm still tempted by the idea of having a new recurrence property to help
> with that. A property that indicates that the recurring event is
> "incomplete" and needs to be "renewed" at a certain date or beyond would
> certainly help in this situation. e.g. I could send out 12 months worth of
> "15th/30th or following Monday" events using RDATEs with the new property
> set to 20071231. In 2008, a client that sees such an event could alert the
> user that a refresh of it is required in some way. This idea has been
> discussed in the context of iTIP clients that cannot handle unbounded rules
> too.
>
> --
> Cyrus Daboo
>
>

Date: Mon, 12 Feb 2007 13:57:18 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Nigel Swinson <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]

Hi Mike,

--On February 12, 2007 9:55:46 AM -0800 Mike Samuel <[email-masked]> 
wrote:

> I agree that's easier but this is a recurrence rule used for certain
> business rules that is expressible today, but not if the proposed
> change goes into effect.
>
> See http://www.google.com/search?q=15th+and+30th+of+the+month for
> examples of where this rule is described.  It seems to be mostly used
> as a way of expressing a bi-monthly deadline for receipt of forms.

Remember that there are always going to be rules that are hard or 
impossible to rally get to work with RRULE. Taking your example: what 
happens if the 15th or 30th is a weekend - one might expect the forms to 
come in the Friday before or perhaps the Monday after - then how do you use 
RRULE (remember only a single RRULE is now allowed in 2445bis)?

The fallback of course is to use a finite set of RDATEs that get "renewed" 
periodically as needed. That fallback could be used if Nigel's proposal 
were to be adopted.

I'm still tempted by the idea of having a new recurrence property to help 
with that. A property that indicates that the recurring event is 
"incomplete" and needs to be "renewed" at a certain date or beyond would 
certainly help in this situation. e.g. I could send out 12 months worth of 
"15th/30th or following Monday" events using RDATEs with the new property 
set to 20071231. In 2008, a client that sees such an event could alert the 
user that a refresh of it is required in some way. This idea has been 
discussed in the context of iTIP clients that cannot handle unbounded rules 
too.

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 9ee14957f7c5ca31f9f00df69a686c98
X-Spam-Score-Summary: 2, 0, 0, 20d930d800e6828a, 2ba588f2bbd3461c, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2525:2559:2563:2682:2685:2693:2828:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3352:3742:3865:3866:3867:3868:3869:3870:3871:3872:3874:3934:3936:3938:3941:4250:4321:4699: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: <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Date: Mon, 12 Feb 2007 18:54:47 -0000
Cc: [email-masked]

> I agree that's easier but this is a recurrence rule used for certain
> business rules that is expressible today, but not if the proposed
> change goes into effect.
>=20
> See http://www.google.com/search?q=3D15th+and+30th+of+the+month for
> examples of where this rule is described.  It seems to be mostly used
> as a way of expressing a bi-monthly deadline for receipt of forms.

Ok, interesting, but I still think it's a corner case that even if the =
standard supports, it is very unlikely that any gui will.  Even then if =
we are talking about businesses, then they work with working days rather =
than calendar days, so if the 30th or the 15th land on a weekend, then =
what they really mean is the next business day that lands after the 15th =
or the 30th, your rule doesn't catch that.

Here are other ways I think the rule is more usefully expressed:

RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D-1,15

RRULE:FREQ=3DDAILY;INTERVAL=3D15

RRULE:FREQ=3DMONTHLY;BYDAY=3DMO,TU,WE,TH,FR;BYSETPOS=3D11,-1

RRULE:FREQ=3DMONTHLY;BYDAY=3DMO,TU,WE,TH,FR;BYSETPOS=3D1,12

RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D15,30
RDATE;VALUE=3DDATE:20070228,20080229,20090228,20090229,20100228

Even a google for BYSETPOS only returns 805 entries, so it can hardly be =
a commonly used part of the standard.  Compare that to BYMONTH which has =
240,000 hits.

I'd be interested in hearing any other opinions on the proposal?

Nigel

Date: Mon, 12 Feb 2007 09:55:46 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]
Reply-To: [email-masked]

Nigel.

I agree that's easier but this is a recurrence rule used for certain
business rules that is expressible today, but not if the proposed
change goes into effect.

See http://www.google.com/search?q=15th+and+30th+of+the+month for
examples of where this rule is described.  It seems to be mostly used
as a way of expressing a bi-monthly deadline for receipt of forms.

cheers,
mike

On 09/02/07, Nigel Swinson <[email-masked]> wrote:
> > To select the 15th and 30th of the month, but to substitute the 28 or
> > 29th for 30th in February:
> >
> >     RRULE:BYMONTHDAY=15,28,29,30;BYSETPOS=1,-1
>
> Wouldn't it be better to write:
>
> RRULE:FREQ=MONTHLY;BYMONTHDAY=-1,15
>
> I know this is slightly different, but demanding the 30th rather than the 31st when available seems like a strange rule...
>
> Nigel
>
>
>
>

Date: Sat, 10 Feb 2007 13:07:44 +1100
From: "Ben Fortuna" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]

Cyrus,

That expand/limit table is extremely useful. Would be great to see
that included in the RFC.

regards,
ben

On 2/10/07, Cyrus Daboo <[email-masked]> wrote:
> Hi Ben,
>
> --On February 10, 2007 12:02:26 PM +1100 Ben Fortuna <[email-masked]>
> wrote:
>
> > Whilst I don't believe it is specified in RFC2445, I don't think it
> > makes sense for FREQ <= XYZ, where a BYXYZ rule is specified. FREQ
> > should always be greater than the BY* rules.
> >
> > Correct me if I'm wrong. :)
>
> Correction: there is nothing to prevent this. In fact there are many
> examples where it is needed.
>
> Take a look at Appendix A in Calconnect's recurrence recommendations
> document:
>
> <http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf>
>
> That shows a table illustrating how BYxx rules and FREQ work together to
> either limit or expand the set of instances in any one rule "iteration".
>
> I think it would be useful to have something like this in 2445bis.
>
> --
> Cyrus Daboo
>
>

-- 
xmpp:[email-masked]
http://blogs.modularity.net.au/thenextbigthing

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: eb906347630b1dab46d4bfc6dbf5013b
X-Spam-Score-Summary: 2, 0, 0, 504fa3ba785ba7d3, 2ba588f2bbd3461c, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:960:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2376:2379:2393:2525:2553:2559:2563:2682:2685:2691:2828:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3352:3770:3865:3866:3867:3869:3870:3871:3872:3934:3936:3938:3941:4250:4605:4699: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: "Ben Fortuna" <[email-masked]>, <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Date: Sat, 10 Feb 2007 01:20:27 -0000
Cc: [email-masked]

> > I'm a bit fuzzy on what effect the BYXYZ rule is
> > supposed to have when FREQ <=3D XYZ
>=20
> Whilst I don't believe it is specified in RFC2445, I don't think it
> makes sense for FREQ <=3D XYZ, where a BYXYZ rule is specified. FREQ
> should always be greater than the BY* rules.

If freq <=3D xyz, the Byxyz adds more entries to the set as detailed =
here:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.1=
0

      BYxxx rule parts modify the recurrence in some manner.  BYxxx rule
      parts for a period of time which is the same or greater than the
      frequency generally reduce or limit the number of occurrences of
      the recurrence generated.  For example, "FREQ=3DDAILY;BYMONTH=3D1"
      reduces the number of recurrence instances from all days (if
      BYMONTH rule part is not present) to all days in January.  BYxxx
      rule parts for a period of time less than the frequency generally
      increase or expand the number of occurrences of the recurrence.
      For example, "FREQ=3DYEARLY;BYMONTH=3D1,2" increases the number of
      days within the yearly recurrence set from 1 (if BYMONTH rule part
      is not present) to 2.

Cheers

Nigel

Date: Fri, 09 Feb 2007 20:16:59 -0500
From: Cyrus Daboo <[email-masked]>
To: Ben Fortuna <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]

Hi Ben,

--On February 10, 2007 12:02:26 PM +1100 Ben Fortuna <[email-masked]> 
wrote:

> Whilst I don't believe it is specified in RFC2445, I don't think it
> makes sense for FREQ <= XYZ, where a BYXYZ rule is specified. FREQ
> should always be greater than the BY* rules.
>
> Correct me if I'm wrong. :)

Correction: there is nothing to prevent this. In fact there are many 
examples where it is needed.

Take a look at Appendix A in Calconnect's recurrence recommendations 
document:

<http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf>

That shows a table illustrating how BYxx rules and FREQ work together to 
either limit or expand the set of instances in any one rule "iteration".

I think it would be useful to have something like this in 2445bis.

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 9c75a27d59d5fec39b59b60dda2bd581
X-Spam-Score-Summary: 2, 0, 0, 78dd21a3dd73d89b, 2ba588f2bbd3461c, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1537:1566:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2553:2559:2562:2828:3027:3865:3866:3867:3868:3869:3870:3871:3872:4699: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: <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Date: Sat, 10 Feb 2007 01:15:42 -0000
Cc: [email-masked]

> To select the 15th and 30th of the month, but to substitute the 28 or
> 29th for 30th in February:
>=20
>     RRULE:BYMONTHDAY=3D15,28,29,30;BYSETPOS=3D1,-1

Wouldn't it be better to write:

RRULE:FREQ=3DMONTHLY;BYMONTHDAY=3D-1,15

I know this is slightly different, but demanding the 30th rather than =
the 31st when available seems like a strange rule...

Nigel

Date: Sat, 10 Feb 2007 12:02:26 +1100
From: "Ben Fortuna" <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]

Mike,

Whilst I don't believe it is specified in RFC2445, I don't think it
makes sense for FREQ <= XYZ, where a BYXYZ rule is specified. FREQ
should always be greater than the BY* rules.

Correct me if I'm wrong. :)

regards,
ben

On 2/10/07, Mike Samuel <[email-masked]> wrote:
> On 09/02/07, Nigel Swinson <[email-masked]> wrote:
> > I'd like to propose the following:
> >
> >  http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.10
> >
> >       The BYSETPOS rule part specifies a COMMA character (US-ASCII
> >       decimal 44) separated list of values which corresponds to the nth
> >       occurrence within the set of events specified by the rule.  Valid
> >       values are 1 to 366 or -366 to -1.  It MUST only be used in
> > +     conjunction with a BYDAY rule part.  For example "the last
> > -     conjunction with another BYxxx rule part.  For example "the last
> >       work day of the month" could be represented as:
> >
> >         FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
> >
> >       Each BYSETPOS value can include a positive (+n) or negative (-n)
> >       integer.  If present, this indicates the nth occurrence of the
> >       specific occurrence within the set of occurences specified by the
> >       rule.
> >
> > As the only usecase I can think of which isn't BYDAY is:
> >
> > FREQ=MONTHLY;BYMONTHDAY=1,31;BYSETPOS=-1
> >
> > But even that isn't terribly useful.  :o/  If you don't like the suggestion, perhaps you can enlighten me on it's utility outwith BYDAY?  Certainly all the examples in the spec use BYDAY.  Would I also be right in saying that the following rule would describe the last working day in March and February, or is it just March?
> >
> > FREQ=YEARLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>
> It's the last one in April :)
>
> I believe
>     FREQ=MONTHLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
> will give the last day in Feb and Apr, at least for our
> implementation.  I'm a bit fuzzy on what effect the BYXYZ rule is
> supposed to have when FREQ <= XYZ

-- 
xmpp:[email-masked]
http://blogs.modularity.net.au/thenextbigthing

Date: Fri, 9 Feb 2007 12:23:22 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]
Reply-To: [email-masked]

On 09/02/07, Nigel Swinson <[email-masked]> wrote:
> I'd like to propose the following:
>
>  http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.10
>
>       The BYSETPOS rule part specifies a COMMA character (US-ASCII
>       decimal 44) separated list of values which corresponds to the nth
>       occurrence within the set of events specified by the rule.  Valid
>       values are 1 to 366 or -366 to -1.  It MUST only be used in
> +     conjunction with a BYDAY rule part.  For example "the last
> -     conjunction with another BYxxx rule part.  For example "the last
>       work day of the month" could be represented as:
>
>         FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>
>       Each BYSETPOS value can include a positive (+n) or negative (-n)
>       integer.  If present, this indicates the nth occurrence of the
>       specific occurrence within the set of occurences specified by the
>       rule.
>
> As the only usecase I can think of which isn't BYDAY is:
>
> FREQ=MONTHLY;BYMONTHDAY=1,31;BYSETPOS=-1
>
> But even that isn't terribly useful.  :o/  If you don't like the suggestion, perhaps you can enlighten me on it's utility outwith BYDAY?  Certainly all the examples in the spec use BYDAY.  Would I also be right in saying that the following rule would describe the last working day in March and February, or is it just March?
>
> FREQ=YEARLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

It's the last one in April :)

I believe
    FREQ=MONTHLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
will give the last day in Feb and Apr, at least for our
implementation.  I'm a bit fuzzy on what effect the BYXYZ rule is
supposed to have when FREQ <= XYZ

Date: Fri, 9 Feb 2007 12:13:26 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY
Cc: [email-masked]
Reply-To: [email-masked]

To select the 15th and 30th of the month, but to substitute the 28 or
29th for 30th in February:

    RRULE:BYMONTHDAY=15,28,29,30;BYSETPOS=1,-1

mike

On 09/02/07, Nigel Swinson <[email-masked]> wrote:
> I'd like to propose the following:
>
>  http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.10
>
>       The BYSETPOS rule part specifies a COMMA character (US-ASCII
>       decimal 44) separated list of values which corresponds to the nth
>       occurrence within the set of events specified by the rule.  Valid
>       values are 1 to 366 or -366 to -1.  It MUST only be used in
> +     conjunction with a BYDAY rule part.  For example "the last
> -     conjunction with another BYxxx rule part.  For example "the last
>       work day of the month" could be represented as:
>
>         FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>
>       Each BYSETPOS value can include a positive (+n) or negative (-n)
>       integer.  If present, this indicates the nth occurrence of the
>       specific occurrence within the set of occurences specified by the
>       rule.
>
> As the only usecase I can think of which isn't BYDAY is:
>
> FREQ=MONTHLY;BYMONTHDAY=1,31;BYSETPOS=-1
>
> But even that isn't terribly useful.  :o/  If you don't like the suggestion, perhaps you can enlighten me on it's utility outwith BYDAY?  Certainly all the examples in the spec use BYDAY.  Would I also be right in saying that the following rule would describe the last working day in March and February, or is it just March?
>
> FREQ=YEARLY;BYMONTH=2,4;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>
> Nigel

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 16b414f3490ba5852e4d342776ac8c76
X-Spam-Score-Summary: 2, 0, 0, 474305b49d130c63, 93dc32ce46acc1f7, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1683:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2525:2553:2559:2563:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3770:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:4250:4605:4699: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: <[email-masked]>
Date: Fri, 9 Feb 2007 19:29:46 -0000
Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY

I'd like to propose the following:

 =
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#section-3.3.1=
0

      The BYSETPOS rule part specifies a COMMA character (US-ASCII
      decimal 44) separated list of values which corresponds to the nth
      occurrence within the set of events specified by the rule.  Valid
      values are 1 to 366 or -366 to -1.  It MUST only be used in
+     conjunction with a BYDAY rule part.  For example "the last
-     conjunction with another BYxxx rule part.  For example "the last
      work day of the month" could be represented as:

        FREQ=3DMONTHLY;BYDAY=3DMO,TU,WE,TH,FR;BYSETPOS=3D-1

      Each BYSETPOS value can include a positive (+n) or negative (-n)
      integer.  If present, this indicates the nth occurrence of the
      specific occurrence within the set of occurences specified by the
      rule.

As the only usecase I can think of which isn't BYDAY is:

FREQ=3DMONTHLY;BYMONTHDAY=3D1,31;BYSETPOS=3D-1

But even that isn't terribly useful.  :o/  If you don't like the =
suggestion, perhaps you can enlighten me on it's utility outwith BYDAY?  =
Certainly all the examples in the spec use BYDAY.  Would I also be right =
in saying that the following rule would describe the last working day in =
March and February, or is it just March?

FREQ=3DYEARLY;BYMONTH=3D2,4;BYDAY=3DMO,TU,WE,TH,FR;BYSETPOS=3D-1

Nigel

Date: Fri, 09 Feb 2007 16:41:19 +0100
From: Eliot Lear <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE
Cc: [email-masked]

Tim,

There seemed to be general agreement on the jabber that at *some* point 
RFC 3283 should be reviewed, but I don't think the chairs would 
entertain that notion until we're done with the work already on our 
plate.  While I can sympathize with people wanting to simplify, the fact 
is that this group has not been able to resolve the issue that there are 
a divergent lot using the standards in question, and some really want 
that rich capability on their beefy 2Ghz 3Gig systems while others pay 
hefty premiums for each kilobyte used.  I can respect both positions, 
and so we are going to need a way to distinguish the two groups, going 
forward.  I do not see that being RFC2445bis.

Eliot

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE
Date: Fri, 9 Feb 2007 09:01:38 -0500

Thoughts: 

1. "Doc, it hurts when I do this!" "Don't do that."   -- I am not going to
argue the consensus of the group on what to leave in or out, but guidelines
documents don't have the same impact in the marketplace. People purchasing
products care if it says "complies to such-and-such an RFC, therefore
interoperates with other vendors", they aren't much impressed by a statement
that says "tries to follow the guidelines as well as it can". Should the
guidelines be yet another RFC for Calendar Interoperability? 

2. Perhaps CalConnect can help with an implementation guideline, with
reports on what interoperates well now, and what doesn't?

3. I'd like to see the RFC finished before writing guidelines - otherwise
we'd be aiming at a (hopefully by now slowly) moving target.

4. I won't have time until March, and since I participate here on my own
time, will not probably be funding my own travel for meetings on this, but I
would help try to write interoperability guidelines - despite #1 above, if
this is what has to be done, then I might be able to help.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andrew N Dowden
Sent: Thursday, February 08, 2007 11:15 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY,MINUTELY and
BYSECOND/BYMINUTE

Eliot Lear wrote:
> The jabber discussion came to consensus that we should not remove the 
> above, but instead that an implementation guide should be written on 
> downgrades.  Are there objections?
>
thank you ..

The consensus now supports my original comment:  labelled implementation
guidelines  instead of removal of features.

Who is leading / pushing this element?

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 09 Feb 2007 17:14:37 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE

Eliot Lear wrote:
> The jabber discussion came to consensus that we should not remove the
> above, but instead that an implementation guide should be written on
> downgrades.  Are there objections?
>
thank you ..

The consensus now supports my original comment:  labelled implementation
guidelines  instead of removal of features.

Who is leading / pushing this element?

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

Date: Thu, 08 Feb 2007 16:43:08 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 67: 4.8.2.5

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

Consensus on the jabber was to go with option (b) for now, but perhaps 
revisit after we complete work with iTIP.  Objections?

Eliot

Date: Thu, 08 Feb 2007 16:35:52 +0100
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <	DTSTART
Cc: [email-masked]

I would like to know if there are objections to this Issue being 
accepted and the text being included, subject to clarifying text about 
VTIMEZONE.

Thanks,

Eliot

Bernard Desruisseaux wrote:
> Reinhold,
>
> In my opinion we need to allow RDATE to be less than DTSTART,
> even more so now that DTSTART should be synchronized with the
> recurrence rule.
>
> Let's say I want to have a meeting today (Monday) with three
> further instances on the next upcoming Tuesday. I could easily
> do that with an RDATE set to today (Monday) and a DTSTART set
> to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.
>
> Cheers,
> Bernard
>
>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>>>  > The "DTSTART" property defines the first instance in the
>>>  > recurrence set.
>>>
>>> I believe this section should clarify that the "RDATE" property
>>> value can actually be earlier in time than the value of the
>>> "DTSTART" property.
>>
>> I always understood this sentence that the DTSTART is always the 
>> first date/time of the event and RDATE cannot be earlier. Otherwise, 
>> to determine whether an event happens today, one would have to look 
>> at all recurrences of all events, future or past. If the DTSTART is 
>> always the first time, then it suffices to look at all events that 
>> have already started at the given date (i.e. DTSTART<=givenDateTime).
>>
>> Cheers,
>> Reinhold
>> - -- - 
>> ------------------------------------------------------------------
>> Version: GnuPG v1.4.3 (GNU/Linux)
>>
>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6
>> RUXtgVx4DX3mzyaAq+CT9j4=
>> =5sgz

Date: Thu, 08 Feb 2007 16:21:39 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE

The jabber discussion came to consensus that we should not remove the 
above, but instead that an implementation guide should be written on 
downgrades.  Are there objections?

Eliot

Date: Thu, 08 Feb 2007 16:15:05 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issues 21 and 54

As the changes are all backward compatible, the jabber session proposes 
that no version bump or new mime type is required.  Objections?

Eliot

Date: Thu, 08 Feb 2007 15:53:36 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] continuing the issue slog on jabber in 5 minutes

[email-masked].  Please join if you can.

Eliot

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Issue 62: RECURRENCE-ID
Date: Wed, 7 Feb 2007 19:40:35 -0500

The archives are full of long, interesting, sometimes vitriolic, =
discussions
of RECURRENCE-ID issues and when or where RECURRENCE-ID should or must
change. This includes appeals to the original RFC authors for =
clarification
of their intent.=20

Before we go down that particular garden path again, I suggest that a
thorough review of the archives on that issue is in order. I will merely
point out that it really helps maintain sanity to remember that the =
unique
identifier of one instance of a recurrence set is composed of three =
values -
UID, SEQUENCE, and RECURRENCE-ID and that RECURRENCE-ID alone does not
uniquely identify the thing you're talking about.

If we were starting from scratch I believe I would be a strong advocate =
for
a recurrence set being separate type of component, or some sort of =
container
for VEVENT/VTODO/VJOURNAL components and that VRECURRENCE (to coin a =
name)
components would have to be added/changed/deleted in their entirety. It
would be less efficient, but I believe a lot more interoperable.=20

Since we are _not_ starting from scratch, let's just make sure the rules =
are
simple and not open to interpretations that cause interoperability =
problems.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Wednesday, February 07, 2007 6:49 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID

Am Don Feb 8 2007 schrieb Neal Gafter:
> Yes, I object.=A0 If a meeting is changed from Monday-Wednesday-Friday =

> to Tuesday-Thursday, and an implementation is required to preserve=20
> recurrence-ID values, I have no idea how one would make sense of the=20
> resulting set of events.=A0 This is one example where the =
recurrence-ID=20
> not only might change, but probably must change.

But isn't it an entirely new event? I mean, before you reschedulled e.g. =

Wednesday's event, now you are reschedulling Thursday's event. In that =
case,
I think it is conceptually cleaner to treat the event after the change =
one
as a new event (with mostly the same settings as the old one, though).

So, yes, effectively you will end up with an event that has a changed
Recurrence-ID compared to before in both viewpoints, but I would not say
it's the same event as before.=20

To make the point even clearer, let's assume you only changed the =
summary of
one Wednesday's event. Now you move the whole sequence to Tue+Thu. I =
don't
think that event from monday and a new, shifted event can really be said =
to
be the same event, can they? (in some cases one might argue, but no in
generality)
One open question is even, whether the change should now apply to Tue or
Thu?=20

Cheers,
Reinhold

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

iD8DBQFFymVqTqjEwhXvPN0RAhEKAJ9XX4lKTsSBwkzkrD3q+y6FO5Or+gCfeffw
0i5jlZlk8GIUEcjb3W3teKY=3D
=3Diw+L
-----END PGP SIGNATURE-----

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID
Date: Thu, 8 Feb 2007 00:48:58 +0100

Am Don Feb 8 2007 schrieb Neal Gafter:
> Yes, I object.� If a meeting is changed from Monday-Wednesday-Friday to
> Tuesday-Thursday, and an implementation is required to preserve
> recurrence-ID values, I have no idea how one would make sense of the
> resulting set of events.� This is one example where the recurrence-ID not
> only might change, but probably must change.

But isn't it an entirely new event? I mean, before you reschedulled e.g. 
Wednesday's event, now you are reschedulling Thursday's event. In that case, 
I think it is conceptually cleaner to treat the event after the change one as 
a new event (with mostly the same settings as the old one, though).

So, yes, effectively you will end up with an event that has a changed 
Recurrence-ID compared to before in both viewpoints, but I would not say it's 
the same event as before. 

To make the point even clearer, let's assume you only changed the summary of 
one Wednesday's event. Now you move the whole sequence to Tue+Thu. I don't 
think that event from monday and a new, shifted event can really be said to 
be the same event, can they? (in some cases one might argue, but no in 
generality)
One open question is even, whether the change should now apply to Tue or Thu? 

Cheers,
Reinhold

- -- 

Date: Wed, 7 Feb 2007 15:16:42 -0800
From: "Neal Gafter" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID
Cc: "[email-masked]" <[email-masked]>

------=_Part_9155_30184668.1170890202536
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/26/07, Eliot Lear <[email-masked]> wrote:
>
> Issue 62 says the following:
>
> > In section 4.8.4.4 Recurrence ID of RFC 2445 it says:
> >
> > > When the definition of the recurrence set for a calendar component
> > > changes, and hence the "SEQUENCE" property value changes, the
> > > "RECURRENCE-ID" for a given recurrence instance might also change.
> >
> > How could one possibly correlate the specific recurrence instance
> > for which the "RECURRENCE-ID" changed?
> >
> > When the definition of the recurrence set for a calendar component
> > changes, specific recurrence instances might be added or removed
> > from the recurrence set.
> >
> > I propose to remove the text mentioned above.
>
> The jabber session participants propose that we remove this text and
> that this matter be revisited in the iTIP revision.  Are there any
> objections?

Yes, I object.  If a meeting is changed from Monday-Wednesday-Friday to
Tuesday-Thursday, and an implementation is required to preserve
recurrence-ID values, I have no idea how one would make sense of the
resulting set of events.  This is one example where the recurrence-ID not
only might change, but probably must change.

------=_Part_9155_30184668.1170890202536
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/26/07, <b class="gmail_sendername">Eliot Lear</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Issue 62 says the following:<br><br>&gt; In section <a href="http://4.8.4.4">4.8.4.4</a> Recurrence ID of RFC 2445 it says:<br>&gt;<br>&gt; &gt; When the definition of the recurrence set for a calendar component<br>&gt; &gt; changes, and hence the &quot;SEQUENCE&quot; property value changes, the
<br>&gt; &gt; &quot;RECURRENCE-ID&quot; for a given recurrence instance might also change.<br>&gt;<br>&gt; How could one possibly correlate the specific recurrence instance<br>&gt; for which the &quot;RECURRENCE-ID&quot; changed?
<br>&gt;<br>&gt; When the definition of the recurrence set for a calendar component<br>&gt; changes, specific recurrence instances might be added or removed<br>&gt; from the recurrence set.<br>&gt;<br>&gt; I propose to remove the text mentioned above.
<br><br>The jabber session participants propose that we remove this text and<br>that this matter be revisited in the iTIP revision.&nbsp;&nbsp;Are there any<br>objections?</blockquote><div><br>Yes, I object.&nbsp; If a meeting is changed from Monday-Wednesday-Friday to Tuesday-Thursday, and an implementation is required to preserve recurrence-ID values, I have no idea how one would make sense of the resulting set of events.&nbsp; This is one example where the recurrence-ID not only 
<span style="font-style: italic;">might</span> change, but probably <span style="font-style: italic;">must</span> change.<br></div></div>

------=_Part_9155_30184668.1170890202536--

Date: Wed, 07 Feb 2007 13:38:41 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME	form required for RDATE
Cc: [email-masked]

Cyrus,

Here's a different approach to address the issue raised by Reinhold.

Earlier in section 4.6.5 Time Zone Component of RFC 2445 it says:

 > The mandatory "TZOFFSETFROM" property gives the UTC offset which is
 > in use when the onset of this time zone observance begins.
 > "TZOFFSETFROM" is combined with "DTSTART" to define the effective
 > onset for the time zone sub-component definition.

I propose to change this text to mention "RDATE" and "RRULE" in
addition to "DTSTART".

Proposed new text:

 > The mandatory "TZOFFSETFROM" property gives the UTC offset which is
 > in use when the onset of this time zone observance begins.
 > "TZOFFSETFROM" is combined with "DTSTART", "RDATE", and "RRULE"
 > to define the effective onset date and times for the time zone
 > sub-component definition.

Furthermore, in section 4.6.5 Time Zone Component of RFC 2445 it says:

 > - The "DTSTART" and the "TZOFFSETTO" properties MUST be used
 > when generating the onset date-time values (instances) from the
 > RRULE.

It is actually "TZOFFSETFROM" that must be used here. As stated
earlier in the section:

 > "TZOFFSETFROM" is combined with "DTSTART" to define the effective
 > onset for the time zone sub-component definition.

Proposed new text:

 > - The "DTSTART" and the "TZOFFSETFROM" properties MUST be used
 > when generating the onset date-time values (instances) from the
 > RRULE.

Cheers,
Bernard

P.S. That makes 3 proposed changes if you count the one in my
      previous message.

Cyrus Daboo wrote:
> Hi Reinhold,
> 
> --On February 7, 2007 5:40:57 PM +0100 Reinhold Kainhofer 
> <[email-masked]> wrote:
> 
>> Right, all VTIMEZONE snipplets that I have seen do it like this. However,
>> I  think it should still be further clarified. In particular, I would
>> write  "...MUST be specified as a local DATE-TIME value with the offset
>> used before  the change occurs.". (or some better wording, as I'm no
>> native speaker)
> 
> It MUST be relative to the TZOFFSETFROM offset in the containing component.
> 
> So I propose modifying Bernard's proposed text to:
> 
>    Alternatively, the "RDATE" property can be used to define the onset of
>    the observance by giving the individual onset date and times. "RDATE"
>    in this usage MUST be specified as a local DATE-TIME value, relative to
>    the UTC offset specified in the TZOFFSETFROM property.
> 
> 

Date: Wed, 07 Feb 2007 13:03:15 -0500
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form	required for RDATE

Hi Reinhold,

--On February 7, 2007 5:40:57 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

> Right, all VTIMEZONE snipplets that I have seen do it like this. However,
> I  think it should still be further clarified. In particular, I would
> write  "...MUST be specified as a local DATE-TIME value with the offset
> used before  the change occurs.". (or some better wording, as I'm no
> native speaker)

It MUST be relative to the TZOFFSETFROM offset in the containing component.

So I propose modifying Bernard's proposed text to:

    Alternatively, the "RDATE" property can be used to define the onset of
    the observance by giving the individual onset date and times. "RDATE"
    in this usage MUST be specified as a local DATE-TIME value, relative to
    the UTC offset specified in the TZOFFSETFROM property.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE
Date: Wed, 7 Feb 2007 17:40:57 +0100

Am Mittwoch, 7. Februar 2007 schrieb Bernard Desruisseaux:
> In section 4.6.5 Time Zone Component of RFC 2445 it says:
>  > Alternatively, the "RDATE" property can be used to define the onset
>  > of the observance by giving the individual onset date and times.
>  > "RDATE" in this usage MUST be specified as a local DATE-TIME value in
>  > UTC time.
>
> That's right!  A *local* DATE-TIME value in *UTC* time!

Ouch!

> Given that all the RDATE properties in the VTIMEZONE examples are
> specified as local DATE-TIME values, and given that I have never
> seen an RDATE specified as a date with UTC time in a VTIMEZONE
>
> component I propose to change this text as follows:
>  > Alternatively, the "RDATE" property can be used to define the onset
>  > of the observance by giving the individual onset date and times.
>  > "RDATE" in this usage MUST be specified as a local DATE-TIME value.

Right, all VTIMEZONE snipplets that I have seen do it like this. However, I 
think it should still be further clarified. In particular, I would write 
"...MUST be specified as a local DATE-TIME value with the offset used before 
the change occurs.". (or some better wording, as I'm no native speaker)

I think that's important in particular as DST shift (for example when the 
shift is from 02:00 to 03:00, as it is the case here in Europe/Vienna, where 
the shift occur collectively at 01:00 UTC on the defined days) is usually 
defined as: The time one second after 01:59:59 is 03:00:00, so there is no 
02:00:00 local time (which is, however, used as the RDATE). [1]

[1] Ofiicially, the DST is defined as beginning at 01:00 UTC, so that time 
already uses the new offset and there is really no 02:00:00 when the clock is 
changed forward: 
http://europa.eu.int/eur-lex/pri/en/oj/dat/2001/l_031/l_03120010202en00210022.pdf

- -- 

Date: Wed, 07 Feb 2007 10:24:52 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE

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

 > Alternatively, the "RDATE" property can be used to define the onset
 > of the observance by giving the individual onset date and times.
 > "RDATE" in this usage MUST be specified as a local DATE-TIME value in
 > UTC time.

That's right!  A *local* DATE-TIME value in *UTC* time!

Given that all the RDATE properties in the VTIMEZONE examples are
specified as local DATE-TIME values, and given that I have never
seen an RDATE specified as a date with UTC time in a VTIMEZONE
component I propose to change this text as follows:

 > Alternatively, the "RDATE" property can be used to define the onset
 > of the observance by giving the individual onset date and times.
 > "RDATE" in this usage MUST be specified as a local DATE-TIME value.

Cheers,
Bernard

Date: Wed, 07 Feb 2007 13:39:52 +0200
From: Aki Niemi <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 74: deprecate PROCEDURE from ACTION property in VALARM

All,

Bernard pointed out an issue we haven't been tracking, but for which
there was audible consensus way back in the IETF65 meeting.

The issue is whether to deprecate "PROCEDURE" from the list of possible
values in an ACTION property in a VALARM.

Reasons for this are that this feature has had very poor interop, and
most importantly is a serious security risk (you don't want to allow
arbitrary code execution this way).

The consensus in IETF65 was for deprecating; any opposite views?

Cheers,
Aki

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE
Date: Mon, 5 Feb 2007 21:21:11 +0100

Am Mon Feb 5 2007 schrieb Bernard Desruisseaux:
> At the 67th IETF Meeting we reached consensus on issue 43 (Section 4.8.5.4
> Recurrence Rule: Allowed value type of DTSTART and DTEND):
>
> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue43
> http://www3.ietf.org/proceedings/06nov/minutes/calsify.txt
>
> and the text was changed accordingly in draft -04:
>
> http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-c
>alsify-rfc2445bis-05.changes.html#rfc.change.#issue43+4.8.5.4_allowed_dateti
>me_form_in_recur_comp.1

+1

Just a thought: Shouldn't the "should" be rather a "SHOULD" in the 
senctence "should be specified as a date with local time and time zone 
reference"?

> Proposed new text:
>  > An individual "VTIMEZONE" calendar component MUST be specified for
>  > each unique "TZID" parameter value specified in the iCalendar object.
>  > In addition, a "VTIMEZONE" calendar component, referred to by a
>  > recurring calendar component, MUST provide valid time zone information
>  > for all recurrence instances.

+1, too.

Cheers,
Reinhold

- -- 

Date: Mon, 05 Feb 2007 14:57:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE
Cc: Calsify WG <[email-masked]>

Hi Bernard,

--On February 5, 2007 2:53:38 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> Proposed new text:
>
>  > An individual "VTIMEZONE" calendar component MUST be specified for
>  > each unique "TZID" parameter value specified in the iCalendar object.
>  > In addition, a "VTIMEZONE" calendar component, referred to by a
>  > recurring calendar component, MUST provide valid time zone information
>  > for all recurrence instances.

+1

-- 
Cyrus Daboo

Date: Mon, 05 Feb 2007 14:53:38 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE
Cc: Calsify WG <[email-masked]>

At the 67th IETF Meeting we reached consensus on issue 43 (Section 4.8.5.4
Recurrence Rule: Allowed value type of DTSTART and DTEND):

http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue43
http://www3.ietf.org/proceedings/06nov/minutes/calsify.txt

and the text was changed accordingly in draft -04:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-05.changes.html#rfc.change.#issue43+4.8.5.4_allowed_datetime_form_in_recur_comp.1

I would like to make a new proposal for issue 72 which is somewhat related
to issue 43.

I would like to *remove* the following paragraph in section 4.6.5 Time Zone
Component:

 > The "VTIMEZONE" calendar component MUST be present if the iCalendar
 > object contains an RRULE that generates dates on both sides of a time
 > zone shift (e.g. both in Standard Time and Daylight Saving Time)
 > unless the iCalendar object intends to convey a floating time (See
 > the section "4.1.10.11 Time" for proper interpretation of floating
 > time). It can be present if the iCalendar object does not contain
 > such a RRULE. In addition, if a RRULE is present, there MUST be valid
 > time zone information for all recurrence instances.

I would like to rephrase the last sentence of the removed paragraph and
move it at the end of this paragraph:

 > An individual "VTIMEZONE" calendar component MUST be specified for
 > each unique "TZID" parameter value specified in the iCalendar object.

Proposed new text:

 > An individual "VTIMEZONE" calendar component MUST be specified for
 > each unique "TZID" parameter value specified in the iCalendar object.
 > In addition, a "VTIMEZONE" calendar component, referred to by a
 > recurring calendar component, MUST provide valid time zone information
 > for all recurrence instances.

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Bernard,
> 
> --On November 5, 2006 5:28:29 PM -0500 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
>> Proposed new text:
>>
>>  > The "VTIMEZONE" calendar component MUST be present if the calendar
>>  > component contains an "RRULE" that generates recurrence instances on
>>  > both sides of a time zone shift (e.g., both in Standard Time and
>>  > Daylight Saving Time) unless the "DTSTART" property of the calendar
>>  > component is specified as a DATE value or as a "floating" DATE-TIME
>>  > value (See section 3.3.12 for proper interpretation of floating time).
> 
> Actually what is being said here is that a recurring event that uses a 
> DATE-TIME value for DTSTART MUST either be floating or local time (i.e. 
> timezone). Whether VTIMEZONE is present or not is then determined by the 
> requirement of having it present if a DTSTART uses a TZID property. i.e. 
> the RRULE does not drive the requirement for VTIMEZONE, instead the 
> DTSTART does.
> 

Date: Mon, 05 Feb 2007 13:14:52 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] All Day Events and DTEND
Cc: [email-masked]

I just realized that the 1st issue is already being tracked as issue 10
in the tracker.

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

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Eliot,
> 
> There are two issues here:
> 
> 1- Handling of DTEND for day events;
> 2- Default duration of day events.
> 
> The 1st issue was brought up on the list in October 2005 by Chris Stoner:
> 
> http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000821.html 
> 
> 
> and I was under the impression that concensus was reached back then.
> Check Reinhold's replies:
> 
> http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000823.html 
> 
> http://lists.osafoundation.org/pipermail/ietf-calsify/2005-October/000824.html 
> 
> 
> 
> The 2nd issue was brought up on the list in November 2006 by myself
> and it is is being tracked as issue 59 in the tracker.
> 
> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001341.html 
> 
> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue59
> 
> Cheers,
> Bernard
> 
> Eliot Lear wrote:
>> While the issues list for 2445bis is officially closed, since I don't 
>> see a normative change in the text coming out of this discussion, I 
>> wouldn't object if someone proposed some example text to make the 
>> matter clear.  Please copy Bernard and this group directly on any such 
>> text.
>>
>> Eliot

Date: Mon, 05 Feb 2007 13:32:08 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issues 68, 69, 70: DST discontinuities

I am currently evaluating each open issue.  These issues each do not 
have specific textual requests for changes.  I have alerted the 
originator of the request.  In the case of Issue 68, my belief is that 
there is general agreement.  In the case of Issue 69, I believe there is 
not necessarily general agreement.  In the case of Issue 70, more 
discussion is needed.

Eliot

Date: Mon, 05 Feb 2007 13:14:27 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 64: Section 4.8.8.2 Request Status: 3 tuples or pairs?

Dear all,

The current proposal to close this issue is as follows from Bernard:
> I think we should only allow pairs and 3-tuples, as such it should be:
>
> statcode   = 1*DIGIT 1*2("." 1*DIGIT)

Barring objection the change will be accepted.

To: Calsify WG <[email-masked]>
From: Jay Batson <[email-masked]>
Date: Fri, 2 Feb 2007 04:19:57 -0500
Subject: [Ietf-calsify] Issues with Security / Spoofing section

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

I was reviewing the latest draft, and finally (after not paying  
sufficient attention previously) noted that the Security section has  
a real problem.

The SPOOFING section is trouble waiting to happen.  Currently, that  
section says:

"... the "Organizer" is the only person authorized to make changes to  
an existing "VEVENT", "VTODO", "VJOURNAL" calendar component...."

(I'm going to restrict my comments to the application of that logic  
to VTODO and VJOURNAL components, because I think VEVENT may have  
different needs.)

ASSERTION:
In general, the current language isn't practical in real life.  When  
VTODOs (and/or VJOURNALs) are used in group task coordination  
applications, it is highly likely that other persons besides the  
"Organizer" will need to be able to modify these components after  
they are created.  Thus, the current restriction is not practical and  
should not remain.

ILLUSTRATIVE BACKGROUND:
Assume:
- a collaborative application that stores tasks assigned to people in  
a project team;
- tasks are stored as VTODO entries in a project.ics file (and  
the .ics file is regularly "synchronized" among team members);
- all users in a project have access to all the project information  
(e.g. all have read-rights to the .ics file)
- assume the software implements the current SPOOFING constraint --  
that only the "Organizer" (task assignor) can modify the task details.
(This is a "generalized" description of what our software does.   
Implementation is different, but the effect is the same.)

Our largest single feature request from users -- by a factor of at  
least 3 over others -- is that users want the "Attendees" to be able  
to modify the VTODO entry.  People often need to modify task  
descriptions to conform with changed requirements, add / modify /  
change assignees (e.g. remove somebody who left the company/team and  
whose PC/software-account you no longer have access to), change dates  
when all agree on the need for change (but the original assignor  
isn't present to make the change), etc.

Note:  In fact, most of our customers want *any* person in the  
project team to be able to modify the task details for *any* task in  
the project -- not just the "Attendees" of a project.  For instance,  
if Sally assigned task A to herself, but went to the hospital to have  
a baby this morning, and Jim is going to assume responsibility for  
it, Jim must have the ability to change the "Attendee" - and probably  
the due-date, too.

In real life, teams work together; it's not a strict hierarchy of  
assignor/assignee, and task detailss change constantly.  Therefore,  
the current SPOOFING restriction is simply not practical if iCalendar  
VTODOs are to be used in anything else than a single-user software  
application.

PROPOSAL:
2445 should simply be silent about who can, or cannot modify (at  
least) VTODO and VJOURNAL components.  Access control is outside the  
scope of the definition of task data.  If some application wants to  
decide to only grant write capabilities to the Organizer it can.  If  
another application wants to maintain ACLs outside the scope of the  
calendar object, it can.  If others want to add x-props to include  
ACL guidance (which could be difficult to enforce if there is no  
secure transit), it can.  It's not the role of 2445 to specify ACLs;  
it is only its role to define the listed components in *this* case  
(of tasks/journals).

I propose the SPOOFING section be rewritten to indicate that the RFC  
is providing no access control for these two components, identify the  
risks of uncontrolled access, and leave security implementation up to  
some externality, e.g. iTIP.  Here is some proposed text (though I  
suspect this needs LOTS of discussion before it goes in):

NEW LANGUAGE:
-----------
SPOOFING:
In this memo, there is no restriction on who is authorized to make  
changes to a "VTODO" or "VJOURNAL" calendar component entry.  Some  
applications using these components in a collaborative setting may  
intentionally desire to provide "Attendees" the ability to update  
this data based on ongoing actual activities, and communicate these  
changes to the "Attendees" as part of the collaborative process.   
Malicious behavior in this context can of course result in data  
changes or loss that is unexpected by the "Attendees".  This is an  
inherent risk in any situation where all "Attendees" are  
collaborating on "VTODO" or "VJOURNAL" entries, and it is up to the  
individuals, or to some other controlling technology, such as iTIP,  
document versioning, or other, to provide any desired control over  
the ability of "Attendees" to make changes in these components.
-----------

Note again that I cannot speak to the implications of changing the  
SPOOFING section relative to VEVENT components.  There must of course  
be SOME description of how to handle VEVENT components.  My language  
proposal above does NOT address this.  Somebody more versed in the  
implications of calendaring must come up with it.

Comments?
-jb

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

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

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>I was reviewing the latest =
draft, and finally (after not paying sufficient attention previously) =
noted that the Security section has a real problem.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The SPOOFING section is =
trouble waiting to happen.=A0 Currently, that section =
says:</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>"... =
the "Organizer" is the only person authorized to make changes to an =
existing "VEVENT", "VTODO", "VJOURNAL" calendar =
component...."</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>(I'm going to restrict my =
comments to the application of that logic to VTODO and VJOURNAL =
components, because I think VEVENT may have different =
needs.)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>ASSERTION:</DIV><DIV>In =
general, the current language isn't practical in real life.=A0 =
When=A0VTODOs (and/or VJOURNALs) are used in group task coordination =
applications, it is highly likely that other persons besides the =
"Organizer" will need to be able to modify these components after they =
are created.=A0 Thus, the current restriction is not practical and =
should not remain.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>ILLUSTRATIVE =
BACKGROUND:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Assume:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">-=A0a collaborative application that stores tasks =
assigned to people in a project team;</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">- tasks =
are stored as VTODO entries in a project.ics file (and the .ics file is =
regularly "synchronized" among team members);</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- all users in a project have access to all the =
project information (e.g. all have read-rights to the .ics =
file)</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">- assume the software implements =
the current SPOOFING constraint -- that only the "Organizer" (task =
assignor) can modify the task details.</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(This is =
a "generalized" description of what our software does.=A0 Implementation =
is different, but the effect is the same.)</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Our largest =
single feature request from users -- by a factor of at least 3 over =
others -- is that users want the "Attendees" to be able to modify the =
VTODO entry.=A0 People often need to modify task descriptions to conform =
with changed requirements, add / modify / change assignees (e.g. remove =
somebody who left the company/team and whose PC/software-account you no =
longer have access to), change dates when all agree on the need for =
change (but the original assignor isn't present to make the change), =
etc.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Note:=A0 In =
fact, most of our customers want=A0*any* person in the project team to =
be able to modify the task details for *any* task in the project -- not =
just the "Attendees" of a project.=A0 For instance, if Sally assigned =
task A to herself, but went to the hospital to have a baby this morning, =
and Jim is going to assume responsibility for it, Jim must have the =
ability to change the "Attendee" - and probably the due-date, =
too.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">In real life, =
teams work together; it's not a strict hierarchy of assignor/assignee, =
and task detailss change constantly.=A0 Therefore, the current SPOOFING =
restriction is simply not practical if iCalendar VTODOs are to be used =
in anything else than a single-user software application.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><BR class=3D"khtml-block-placeholder"></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">PROPOSAL:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">2445 should =
simply be silent about who can, or cannot modify (at least) VTODO and =
VJOURNAL components.=A0 Access control is outside the scope of the =
definition of task data.=A0 If some application wants to decide to only =
grant write capabilities to the Organizer it can.=A0 If another =
application wants to maintain ACLs outside the scope of the calendar =
object, it can.=A0 If others want to add x-props to include ACL guidance =
(which could be difficult to enforce if there is no secure transit), it =
can.=A0 It's not the role of 2445 to specify ACLs; it is only its role =
to define the listed components in *this* case (of =
tasks/journals).</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I propose the =
SPOOFING section be rewritten to indicate that the RFC is providing no =
access control for these two components, identify the risks of =
uncontrolled access, and leave security implementation up to some =
externality, e.g. iTIP.=A0 Here is some proposed text (though I suspect =
this needs LOTS of discussion before it goes in):</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><BR class=3D"khtml-block-placeholder"></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">NEW LANGUAGE:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">-----------</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">SPOOFING:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">In this memo, there is no restriction on who is =
authorized to make changes to a "VTODO" or "VJOURNAL" calendar component =
entry.=A0 Some applications using these components in a collaborative =
setting may intentionally desire to provide "Attendees" the ability to =
update this data based on ongoing actual activities, and communicate =
these changes to the "Attendees" as part of the collaborative process.=A0 =
Malicious behavior in this context can of course result in data changes =
or loss that is unexpected by the "Attendees".=A0 This is an inherent =
risk in any situation where all "Attendees" are collaborating on "VTODO" =
or "VJOURNAL" entries, and it is up to the individuals, or to some other =
controlling technology, such as iTIP, document versioning, or other, to =
provide any desired control over the ability of "Attendees" to make =
changes in these components.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">-----------</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Note again =
that I cannot speak to the implications of changing the SPOOFING section =
relative to VEVENT components.=A0 There must of course be SOME =
description of how to handle VEVENT components.=A0 My language proposal =
above does NOT address this.=A0 Somebody more versed in the implications =
of calendaring must come up with it.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Comments?</DIV><DIV>-jb</DIV>=
<BR><DIV> <SPAN class=3D"Apple-style-span" style=3D"border-collapse: =
separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: =
0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; =
"><DIV>-------------</DIV><DIV>Jay Batson</DIV><DIV><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV=
><DIV>+1-978-824-0111 (w)</DIV><DIV>+1-978-758-1599 (m)</DIV><BR =
class=3D"Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>=

--Apple-Mail-33-974753412--