From batsonjay at plumcanary.com Fri Feb 2 01:19:57 2007 From: batsonjay at plumcanary.com (Jay Batson) Date: Fri Feb 2 01:22:20 2007 Subject: [Ietf-calsify] Issues with Security / Spoofing section Message-ID: 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 batsonjay@plumcanary.com +1-978-824-0111 (w) +1-978-758-1599 (m) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070202/e3c0d066/attachment.html From lear at cisco.com Mon Feb 5 04:14:27 2007 From: lear at cisco.com (Eliot Lear) Date: Mon Feb 5 04:15:31 2007 Subject: [Ietf-calsify] Issue 64: Section 4.8.8.2 Request Status: 3 tuples or pairs? Message-ID: <45C71FA3.9060906@cisco.com> 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. From lear at cisco.com Mon Feb 5 04:32:08 2007 From: lear at cisco.com (Eliot Lear) Date: Mon Feb 5 04:33:05 2007 Subject: [Ietf-calsify] Issues 68, 69, 70: DST discontinuities Message-ID: <45C723C8.2090507@cisco.com> 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 From bernard.desruisseaux at oracle.com Mon Feb 5 10:14:52 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Feb 5 10:16:39 2007 Subject: [Ietf-calsify] All Day Events and DTEND In-Reply-To: <45B7CF12.3010109@oracle.com> References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> Message-ID: <45C7741C.8090608@oracle.com> 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 >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From bernard.desruisseaux at oracle.com Mon Feb 5 11:53:38 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Feb 5 11:56:32 2007 Subject: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE In-Reply-To: <80EA29F7229D909D0A63A07A@ninevah.local> References: <454E658D.9050804@oracle.com> <80EA29F7229D909D0A63A07A@ninevah.local> Message-ID: <45C78B42.4010409@oracle.com> 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 > 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. > From cyrus at daboo.name Mon Feb 5 11:57:13 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Feb 5 11:58:26 2007 Subject: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE In-Reply-To: <45C78B42.4010409@oracle.com> References: <454E658D.9050804@oracle.com> <80EA29F7229D909D0A63A07A@ninevah.local> <45C78B42.4010409@oracle.com> Message-ID: <57B79AA3AD07EA83D694BC55@caldav.apple.com> Hi Bernard, --On February 5, 2007 2:53:38 PM -0500 Bernard Desruisseaux 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 From reinhold at kainhofer.com Mon Feb 5 12:21:11 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Mon Feb 5 12:22:04 2007 Subject: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE In-Reply-To: <45C78B42.4010409@oracle.com> References: <454E658D.9050804@oracle.com> <80EA29F7229D909D0A63A07A@ninevah.local> <45C78B42.4010409@oracle.com> Message-ID: <200702052121.14933.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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) iD8DBQFFx5G6TqjEwhXvPN0RAgTyAJwMXNdoucQRj/mGhQOCDhwJWUjy2QCfeVdZ YK4Jo0PMUaif5qvu605UnxE= =jRm/ -----END PGP SIGNATURE----- From aki.niemi at nokia.com Wed Feb 7 03:39:52 2007 From: aki.niemi at nokia.com (Aki Niemi) Date: Wed Feb 7 03:41:09 2007 Subject: [Ietf-calsify] Issue 74: deprecate PROCEDURE from ACTION property in VALARM Message-ID: <45C9BA88.8050404@nokia.com> 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 bernard.desruisseaux at oracle.com Wed Feb 7 07:24:52 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Feb 7 07:27:34 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE Message-ID: <45C9EF44.7090901@oracle.com> 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 From reinhold at kainhofer.com Wed Feb 7 08:40:57 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Wed Feb 7 08:42:28 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE In-Reply-To: <45C9EF44.7090901@oracle.com> References: <45C9EF44.7090901@oracle.com> Message-ID: <200702071741.02928.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFygEeTqjEwhXvPN0RAkSKAKCkTS4OO8vDPFhMclxxBq8corQhBwCgz0sK g1MYOBtY2cGUjri2ovrCg7Y= =ig+Y -----END PGP SIGNATURE----- From cyrus at daboo.name Wed Feb 7 10:03:15 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed Feb 7 10:04:39 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE In-Reply-To: <200702071741.02928.reinhold@kainhofer.com> References: <45C9EF44.7090901@oracle.com> <200702071741.02928.reinhold@kainhofer.com> Message-ID: <75020DB80255FB52A72E55F3@caldav.apple.com> Hi Reinhold, --On February 7, 2007 5:40:57 PM +0100 Reinhold Kainhofer 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 bernard.desruisseaux at oracle.com Wed Feb 7 10:38:41 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Feb 7 10:41:31 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE In-Reply-To: <75020DB80255FB52A72E55F3@caldav.apple.com> References: <45C9EF44.7090901@oracle.com> <200702071741.02928.reinhold@kainhofer.com> <75020DB80255FB52A72E55F3@caldav.apple.com> Message-ID: <45CA1CB1.5020703@oracle.com> 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 > 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. > > From gafter at google.com Wed Feb 7 15:16:42 2007 From: gafter at google.com (Neal Gafter) Date: Wed Feb 7 15:17:53 2007 Subject: [Ietf-calsify] Issue 62: RECURRENCE-ID In-Reply-To: <45BA2D2E.5040603@cisco.com> References: <45BA2D2E.5040603@cisco.com> Message-ID: <76f0ff970702071516n2075005as4920db3369bcfc38@mail.gmail.com> On 1/26/07, Eliot Lear 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070207/13253c1a/attachment.htm From reinhold at kainhofer.com Wed Feb 7 15:48:58 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Wed Feb 7 15:49:48 2007 Subject: [Ietf-calsify] Issue 62: RECURRENCE-ID In-Reply-To: <76f0ff970702071516n2075005as4920db3369bcfc38@mail.gmail.com> References: <45BA2D2E.5040603@cisco.com> <76f0ff970702071516n2075005as4920db3369bcfc38@mail.gmail.com> Message-ID: <200702080048.58468.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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= =iw+L -----END PGP SIGNATURE----- From TimHare at comcast.net Wed Feb 7 16:40:35 2007 From: TimHare at comcast.net (Tim Hare) Date: Wed Feb 7 16:41:57 2007 Subject: [Ietf-calsify] Issue 62: RECURRENCE-ID In-Reply-To: <200702080048.58468.reinhold@kainhofer.com> Message-ID: <20070208004058.CDD8214225A@laweleka.osafoundation.org> 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. 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. 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Reinhold Kainhofer Sent: Wednesday, February 07, 2007 6:49 PM To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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= =iw+L -----END PGP SIGNATURE----- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From lear at cisco.com Thu Feb 8 06:53:36 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Feb 8 06:54:45 2007 Subject: [Ietf-calsify] continuing the issue slog on jabber in 5 minutes Message-ID: <45CB3970.5000907@cisco.com> calsify@jabber.ietf.org. Please join if you can. Eliot From lear at cisco.com Thu Feb 8 07:15:05 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Feb 8 07:16:06 2007 Subject: [Ietf-calsify] Issues 21 and 54 Message-ID: <45CB3E79.10805@cisco.com> As the changes are all backward compatible, the jabber session proposes that no version bump or new mime type is required. Objections? Eliot From lear at cisco.com Thu Feb 8 07:21:39 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Feb 8 07:22:41 2007 Subject: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE Message-ID: <45CB4003.6030008@cisco.com> 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 From lear at cisco.com Thu Feb 8 07:35:52 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Feb 8 07:37:00 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <454F4005.7040201@oracle.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> Message-ID: <45CB4358.7070900@cisco.com> 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 > > Reinhold Kainhofer wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>> > The "DTSTART" property defines the first instance in the >>> > recurrence set. >>> >>> I believe this section should clarify that the "RDATE" property >>> value can actually be earlier in time than the value of the >>> "DTSTART" property. >> >> I always understood this sentence that the DTSTART is always the >> first date/time of the event and RDATE cannot be earlier. Otherwise, >> to determine whether an event happens today, one would have to look >> at all recurrences of all events, future or past. If the DTSTART is >> always the first time, then it suffices to look at all events that >> have already started at the given date (i.e. DTSTART<=givenDateTime). >> >> Cheers, >> Reinhold >> - -- - >> ------------------------------------------------------------------ >> Reinhold Kainhofer, Vienna University of Technology, Austria >> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >> * Financial and Actuarial Mathematics, TU Wien, >> http://www.fam.tuwien.ac.at/ >> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.3 (GNU/Linux) >> >> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >> RUXtgVx4DX3mzyaAq+CT9j4= >> =5sgz >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From lear at cisco.com Thu Feb 8 07:43:08 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Feb 8 07:44:10 2007 Subject: [Ietf-calsify] Issue 67: 4.8.2.5 Message-ID: <45CB450C.4070504@cisco.com> > > 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 From andrew_dowden at softdesign.net.nz Thu Feb 8 20:14:37 2007 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Thu Feb 8 20:15:46 2007 Subject: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE In-Reply-To: <45CB4003.6030008@cisco.com> References: <45CB4003.6030008@cisco.com> Message-ID: <45CBF52D.6020307@softdesign.net.nz> 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 From TimHare at comcast.net Fri Feb 9 06:01:38 2007 From: TimHare at comcast.net (Tim Hare) Date: Fri Feb 9 06:04:11 2007 Subject: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE In-Reply-To: <45CBF52D.6020307@softdesign.net.nz> Message-ID: <20070209140313.88D1414225B@laweleka.osafoundation.org> 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Andrew N Dowden Sent: Thursday, February 08, 2007 11:15 PM To: ietf-calsify@osafoundation.org 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 Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From lear at cisco.com Fri Feb 9 07:41:19 2007 From: lear at cisco.com (Eliot Lear) Date: Fri Feb 9 07:42:27 2007 Subject: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE In-Reply-To: <20070209140313.88D1414225B@laweleka.osafoundation.org> References: <20070209140313.88D1414225B@laweleka.osafoundation.org> Message-ID: <45CC961F.6010901@cisco.com> 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 Nigel.Swinson at rockliffe.com Fri Feb 9 11:29:46 2007 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Fri Feb 9 11:29:47 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY Message-ID: <004e01c74c80$a969b330$972c2a0a@nigelhome> 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 From mikesamuel at gmail.com Fri Feb 9 12:13:26 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Fri Feb 9 12:14:26 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <004e01c74c80$a969b330$972c2a0a@nigelhome> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> Message-ID: <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> 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 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From mikesamuel at gmail.com Fri Feb 9 12:23:22 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Fri Feb 9 12:24:20 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <004e01c74c80$a969b330$972c2a0a@nigelhome> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> Message-ID: <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> On 09/02/07, Nigel Swinson 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 From benfortuna at gmail.com Fri Feb 9 17:02:26 2007 From: benfortuna at gmail.com (Ben Fortuna) Date: Fri Feb 9 17:03:39 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> Message-ID: <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> 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 wrote: > On 09/02/07, Nigel Swinson 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- xmpp:benfortuna@gmail.com http://blogs.modularity.net.au/thenextbigthing From Nigel.Swinson at rockliffe.com Fri Feb 9 17:15:42 2007 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Fri Feb 9 17:16:25 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> Message-ID: <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> > 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 From cyrus at daboo.name Fri Feb 9 17:16:59 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Fri Feb 9 17:18:08 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> Message-ID: <29E3DC1CC78FEB4FBF4C3266@ninevah.local> Hi Ben, --On February 10, 2007 12:02:26 PM +1100 Ben Fortuna 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: 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 From Nigel.Swinson at rockliffe.com Fri Feb 9 17:20:27 2007 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Fri Feb 9 17:21:09 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY References: <004e01c74c80$a969b330$972c2a0a@nigelhome><178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> Message-ID: <008201c74cb1$a6cc55c0$972c2a0a@nigelhome> > > I'm a bit fuzzy on what effect the BYXYZ rule is > > supposed to have when FREQ <= XYZ > > 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. If freq <= 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.10 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=DAILY;BYMONTH=1" 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=YEARLY;BYMONTH=1,2" increases the number of days within the yearly recurrence set from 1 (if BYMONTH rule part is not present) to 2. Cheers Nigel From benfortuna at gmail.com Fri Feb 9 18:07:44 2007 From: benfortuna at gmail.com (Ben Fortuna) Date: Fri Feb 9 18:08:51 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <29E3DC1CC78FEB4FBF4C3266@ninevah.local> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> <29E3DC1CC78FEB4FBF4C3266@ninevah.local> Message-ID: <91390c30702091807o651bc51aqc9b102f2d40639c7@mail.gmail.com> 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 wrote: > Hi Ben, > > --On February 10, 2007 12:02:26 PM +1100 Ben Fortuna > 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: > > > > 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:benfortuna@gmail.com http://blogs.modularity.net.au/thenextbigthing From mikesamuel at gmail.com Mon Feb 12 09:55:46 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Mon Feb 12 09:56:48 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> Message-ID: <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> 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 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 > > > > From Nigel.Swinson at rockliffe.com Mon Feb 12 10:54:47 2007 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Mon Feb 12 10:55:23 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> Message-ID: <016901c74ed7$45ae6260$972c2a0a@nigelhome> > 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. 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. I'd be interested in hearing any other opinions on the proposal? Nigel From cyrus at daboo.name Mon Feb 12 10:57:18 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Feb 12 10:58:34 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> Message-ID: <5AD5D946DD0293CBCE3E719C@caldav.apple.com> Hi Mike, --On February 12, 2007 9:55:46 AM -0800 Mike Samuel 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 From mikesamuel at gmail.com Mon Feb 12 12:19:27 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Mon Feb 12 12:20:26 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <5AD5D946DD0293CBCE3E719C@caldav.apple.com> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> <5AD5D946DD0293CBCE3E719C@caldav.apple.com> Message-ID: <178b8d440702121219wdc7d86aw3a2c4a5a144b1198@mail.gmail.com> On 12/02/07, Cyrus Daboo wrote: > Hi Mike, > > --On February 12, 2007 9:55:46 AM -0800 Mike Samuel > 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 > > From mikesamuel at gmail.com Mon Feb 12 12:37:21 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Mon Feb 12 12:38:21 2007 Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <016901c74ed7$45ae6260$972c2a0a@nigelhome> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> <016901c74ed7$45ae6260$972c2a0a@nigelhome> Message-ID: <178b8d440702121237u45b3774ft3d9b3c6fae3504d9@mail.gmail.com> On 12/02/07, Nigel Swinson 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 > From TimHare at comcast.net Mon Feb 12 14:52:18 2007 From: TimHare at comcast.net (TimHare@comcast.net) Date: Mon Feb 12 14:53:17 2007 Subject: ***SPAM*** Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY Message-ID: <021220072252.13433.45D0EFA2000B35880000347922007637040A9D0EB80307AB@comcast.net> I like the recurrence property, as long as the standard sets a "MUST" rule that limits the duration allowed until the required refresh - the time period can't be too long or the limited clients will have effectively the same problem as the unlimited-recurrences case. I am not at my home machine, so I can't see my previous e-mail, but I think I previously proposed promoting recurrence sets to a new VRECUR component; I would also support combining the "must refresh" property into that idea as well. Having VRECUR components separate from VEVENT components would simplify some things for recurrences, allowing us to have different properties for recurring events and to simplify one-instance events. Tim Hare Interested Bystander, Non-Inc. -------------- Original message -------------- From: Cyrus Daboo > Hi Mike, > > --On February 12, 2007 9:55:46 AM -0800 Mike Samuel > 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 > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070212/c5a0e2a7/attachment.html From bernard.desruisseaux at oracle.com Tue Feb 13 08:13:03 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Feb 13 08:15:32 2007 Subject: [Ietf-calsify] [Fwd: 2445bis: clarify allowed value types of date-time property combinations] Message-ID: <45D1E38F.5050104@oracle.com> [ 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 > To: Bernard Desruisseaux > CC: ietf-calsify@osafoundation.org > > 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 From cyrus at daboo.name Tue Feb 13 08:23:40 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Tue Feb 13 08:25:14 2007 Subject: [Ietf-calsify] Re: [Fwd: 2445bis: clarify allowed value types of date-time property combinations] In-Reply-To: <45D1E38F.5050104@oracle.com> References: <45D1E38F.5050104@oracle.com> Message-ID: Hi Bernard, --On February 13, 2007 11:13:03 AM -0500 Bernard Desruisseaux 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 > > To: Bernard Desruisseaux > > CC: ietf-calsify@osafoundation.org > > > > 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 From lear at cisco.com Thu Feb 15 06:55:18 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Feb 15 06:56:17 2007 Subject: [Ietf-calsify] jabber starts in 5 minutes! Message-ID: <45D47456.5040302@cisco.com> See you there! From bernard.desruisseaux at oracle.com Thu Feb 15 12:51:49 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Feb 15 12:54:30 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <45CB4358.7070900@cisco.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> Message-ID: <45D4C7E5.5010507@oracle.com> 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 >> >> Reinhold Kainhofer wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>> > The "DTSTART" property defines the first instance in the >>>> > recurrence set. >>>> >>>> I believe this section should clarify that the "RDATE" property >>>> value can actually be earlier in time than the value of the >>>> "DTSTART" property. >>> >>> I always understood this sentence that the DTSTART is always the >>> first date/time of the event and RDATE cannot be earlier. Otherwise, >>> to determine whether an event happens today, one would have to look >>> at all recurrences of all events, future or past. If the DTSTART is >>> always the first time, then it suffices to look at all events that >>> have already started at the given date (i.e. DTSTART<=givenDateTime). >>> >>> Cheers, >>> Reinhold >>> - -- - >>> ------------------------------------------------------------------ >>> Reinhold Kainhofer, Vienna University of Technology, Austria >>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>> * Financial and Actuarial Mathematics, TU Wien, >>> http://www.fam.tuwien.ac.at/ >>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.3 (GNU/Linux) >>> >>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>> RUXtgVx4DX3mzyaAq+CT9j4= >>> =5sgz >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> From bernard.desruisseaux at oracle.com Thu Feb 15 12:53:31 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Feb 15 12:56:36 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM Message-ID: <45D4C84B.20800@oracle.com> 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 From gsexton at mhsoftware.com Thu Feb 15 13:05:24 2007 From: gsexton at mhsoftware.com (George Sexton) Date: Thu Feb 15 13:06:26 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <45D4C7E5.5010507@oracle.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> Message-ID: <45D4CB14.1010701@mhsoftware.com> 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 >>> >>> Reinhold Kainhofer wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>>> > The "DTSTART" property defines the first instance in the >>>>> > recurrence set. >>>>> >>>>> I believe this section should clarify that the "RDATE" property >>>>> value can actually be earlier in time than the value of the >>>>> "DTSTART" property. >>>> >>>> I always understood this sentence that the DTSTART is always the >>>> first date/time of the event and RDATE cannot be earlier. >>>> Otherwise, to determine whether an event happens today, one would >>>> have to look at all recurrences of all events, future or past. If >>>> the DTSTART is always the first time, then it suffices to look at >>>> all events that have already started at the given date (i.e. >>>> DTSTART<=givenDateTime). >>>> >>>> Cheers, >>>> Reinhold >>>> - -- - >>>> ------------------------------------------------------------------ >>>> Reinhold Kainhofer, Vienna University of Technology, Austria >>>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>>> * Financial and Actuarial Mathematics, TU Wien, >>>> http://www.fam.tuwien.ac.at/ >>>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.3 (GNU/Linux) >>>> >>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>>> RUXtgVx4DX3mzyaAq+CT9j4= >>>> =5sgz >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> Ietf-calsify mailing list >>>> Ietf-calsify@osafoundation.org >>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>> > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From bernard.desruisseaux at oracle.com Thu Feb 15 13:10:13 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Feb 15 13:12:47 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? Message-ID: <45D4CC35.1040508@oracle.com> 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 From jeffrey at osafoundation.org Thu Feb 15 13:13:15 2007 From: jeffrey at osafoundation.org (Jeffrey Harris) Date: Thu Feb 15 13:14:16 2007 Subject: [Ietf-calsify] Exchange and new timezones Message-ID: <45D4CCEB.1090608@osafoundation.org> 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 From bernard.desruisseaux at oracle.com Thu Feb 15 13:42:31 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Feb 15 13:45:20 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <45D4CB14.1010701@mhsoftware.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> Message-ID: <45D4D3C7.8000307@oracle.com> 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 >>>> >>>> Reinhold Kainhofer wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>>>> > The "DTSTART" property defines the first instance in the >>>>>> > recurrence set. >>>>>> >>>>>> I believe this section should clarify that the "RDATE" property >>>>>> value can actually be earlier in time than the value of the >>>>>> "DTSTART" property. >>>>> >>>>> I always understood this sentence that the DTSTART is always the >>>>> first date/time of the event and RDATE cannot be earlier. >>>>> Otherwise, to determine whether an event happens today, one would >>>>> have to look at all recurrences of all events, future or past. If >>>>> the DTSTART is always the first time, then it suffices to look at >>>>> all events that have already started at the given date (i.e. >>>>> DTSTART<=givenDateTime). >>>>> >>>>> Cheers, >>>>> Reinhold >>>>> - -- - >>>>> ------------------------------------------------------------------ >>>>> Reinhold Kainhofer, Vienna University of Technology, Austria >>>>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>>>> * Financial and Actuarial Mathematics, TU Wien, >>>>> http://www.fam.tuwien.ac.at/ >>>>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>>>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.3 (GNU/Linux) >>>>> >>>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>>>> RUXtgVx4DX3mzyaAq+CT9j4= >>>>> =5sgz >>>>> -----END PGP SIGNATURE----- >>>>> _______________________________________________ >>>>> Ietf-calsify mailing list >>>>> Ietf-calsify@osafoundation.org >>>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>> _______________________________________________ >>>> Ietf-calsify mailing list >>>> Ietf-calsify@osafoundation.org >>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>> >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > From gsexton at mhsoftware.com Thu Feb 15 13:53:14 2007 From: gsexton at mhsoftware.com (George Sexton) Date: Thu Feb 15 13:54:18 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <45D4D3C7.8000307@oracle.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> <45D4D3C7.8000307@oracle.com> Message-ID: <45D4D64A.6030709@mhsoftware.com> 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 >>>>> >>>>> Reinhold Kainhofer wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>>>>> > The "DTSTART" property defines the first instance in the >>>>>>> > recurrence set. >>>>>>> >>>>>>> I believe this section should clarify that the "RDATE" property >>>>>>> value can actually be earlier in time than the value of the >>>>>>> "DTSTART" property. >>>>>> >>>>>> I always understood this sentence that the DTSTART is always the >>>>>> first date/time of the event and RDATE cannot be earlier. >>>>>> Otherwise, to determine whether an event happens today, one would >>>>>> have to look at all recurrences of all events, future or past. If >>>>>> the DTSTART is always the first time, then it suffices to look at >>>>>> all events that have already started at the given date (i.e. >>>>>> DTSTART<=givenDateTime). >>>>>> >>>>>> Cheers, >>>>>> Reinhold >>>>>> - -- - >>>>>> ------------------------------------------------------------------ >>>>>> Reinhold Kainhofer, Vienna University of Technology, Austria >>>>>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>>>>> * Financial and Actuarial Mathematics, TU Wien, >>>>>> http://www.fam.tuwien.ac.at/ >>>>>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>>>>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG v1.4.3 (GNU/Linux) >>>>>> >>>>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>>>>> RUXtgVx4DX3mzyaAq+CT9j4= >>>>>> =5sgz >>>>>> -----END PGP SIGNATURE----- >>>>>> _______________________________________________ >>>>>> Ietf-calsify mailing list >>>>>> Ietf-calsify@osafoundation.org >>>>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>>> _______________________________________________ >>>>> Ietf-calsify mailing list >>>>> Ietf-calsify@osafoundation.org >>>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>>> >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>> >> > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From reinhold at kainhofer.com Thu Feb 15 14:35:38 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Thu Feb 15 14:36:42 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? In-Reply-To: <45D4CC35.1040508@oracle.com> References: <45D4CC35.1040508@oracle.com> Message-ID: <200702152335.40461.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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) iD8DBQFF1OA8TqjEwhXvPN0RAmfvAKCLY1n1ho8M1DlZ42iAGI1Nuf9AnwCgp0J5 cenbhO/IL3ap3qTgT1VhfjQ= =PVE8 -----END PGP SIGNATURE----- From bernard.desruisseaux at oracle.com Thu Feb 15 17:41:05 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Feb 15 17:43:01 2007 Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? In-Reply-To: <200702152335.40461.reinhold@kainhofer.com> References: <45D4CC35.1040508@oracle.com> <200702152335.40461.reinhold@kainhofer.com> Message-ID: <45D50BB1.3040005@oracle.com> Hi Reinhold, Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, Austria > email: reinhold@kainhofer.com, 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) > > iD8DBQFF1OA8TqjEwhXvPN0RAmfvAKCLY1n1ho8M1DlZ42iAGI1Nuf9AnwCgp0J5 > cenbhO/IL3ap3qTgT1VhfjQ= > =PVE8 > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From cyrus at daboo.name Fri Feb 16 07:12:30 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Fri Feb 16 07:13:41 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <45D4D64A.6030709@mhsoftware.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> <45D4D3C7.8000307@oracle.com> <45D4D64A.6030709@mhsoftware.com> Message-ID: <16A3AF236A50F93ADD607820@caldav.apple.com> Hi George, --On February 15, 2007 2:53:14 PM -0700 George Sexton 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 From gsexton at mhsoftware.com Fri Feb 16 08:42:58 2007 From: gsexton at mhsoftware.com (George Sexton) Date: Fri Feb 16 08:43:58 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <16A3AF236A50F93ADD607820@caldav.apple.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> <45D4D3C7.8000307@oracle.com> <45D4D64A.6030709@mhsoftware.com> <16A3AF236A50F93ADD607820@caldav.apple.com> Message-ID: <45D5DF12.4040701@mhsoftware.com> 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 > 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/ From reinhold at kainhofer.com Fri Feb 16 09:21:53 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Fri Feb 16 09:23:04 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE <=?iso-8859-1?q?=09DTSTART?= In-Reply-To: <45D5DF12.4040701@mhsoftware.com> References: <454E66AA.9060809@oracle.com> <16A3AF236A50F93ADD607820@caldav.apple.com> <45D5DF12.4040701@mhsoftware.com> Message-ID: <200702161821.58133.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1eg2TqjEwhXvPN0RAlK1AKCGUy52PEXheAgTZ5ietz9Btes7KQCgsZh7 VVCrHFWJKnpZDyskuA834yg= =YOSl -----END PGP SIGNATURE----- From gsexton at mhsoftware.com Fri Feb 16 09:35:46 2007 From: gsexton at mhsoftware.com (George Sexton) Date: Fri Feb 16 09:36:47 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <200702161821.58133.reinhold@kainhofer.com> References: <454E66AA.9060809@oracle.com> <16A3AF236A50F93ADD607820@caldav.apple.com> <45D5DF12.4040701@mhsoftware.com> <200702161821.58133.reinhold@kainhofer.com> Message-ID: <45D5EB72.5040507@mhsoftware.com> Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 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 > > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, Austria > email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ > * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ > * K Desktop Environment, http://www.kde.org, KOrganizer maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFF1eg2TqjEwhXvPN0RAlK1AKCGUy52PEXheAgTZ5ietz9Btes7KQCgsZh7 > VVCrHFWJKnpZDyskuA834yg= > =YOSl > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From reinhold at kainhofer.com Fri Feb 16 10:46:32 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Fri Feb 16 10:47:47 2007 Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART In-Reply-To: <45D5EB72.5040507@mhsoftware.com> References: <454E66AA.9060809@oracle.com> <200702161821.58133.reinhold@kainhofer.com> <45D5EB72.5040507@mhsoftware.com> Message-ID: <200702161946.37288.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Freitag, 16. Februar 2007 schrieb George Sexton: > Reinhold Kainhofer wrote: > > 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 > 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1fwNTqjEwhXvPN0RAjP7AJ9lz+dgm/vf+Xi2udpo28eNn70wQACgzMJG 28UgXyYh6cLYk2jXDkPLcos= =KcRT -----END PGP SIGNATURE----- From bernard.desruisseaux at oracle.com Mon Feb 19 08:39:23 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Feb 19 08:41:44 2007 Subject: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] In-Reply-To: <45C7741C.8090608@oracle.com> References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> <45C7741C.8090608@oracle.com> Message-ID: <45D9D2BB.3000803@oracle.com> 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 >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From mgk at webfeet.co.uk Mon Feb 19 13:30:43 2007 From: mgk at webfeet.co.uk (Martin Kiff) Date: Mon Feb 19 13:31:50 2007 Subject: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] In-Reply-To: <45D9D2BB.3000803@oracle.com> References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> <45C7741C.8090608@oracle.com> <45D9D2BB.3000803@oracle.com> Message-ID: <45DA1703.1040700@webfeet.co.uk> 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 From cyrus at daboo.name Mon Feb 19 13:33:28 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Feb 19 13:34:56 2007 Subject: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] In-Reply-To: <45D9D2BB.3000803@oracle.com> References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> <45C7741C.8090608@oracle.com> <45D9D2BB.3000803@oracle.com> Message-ID: Hi Bernard, --On February 19, 2007 11:39:23 AM -0500 Bernard Desruisseaux 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 From Nigel.Swinson at rockliffe.com Mon Feb 19 16:00:54 2007 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Mon Feb 19 16:01:10 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. Message-ID: <014c01c75482$31efa8a0$0202fea9@nigelhome> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070220/ce92069f/attachment.html From gsexton at mhsoftware.com Mon Feb 19 20:19:33 2007 From: gsexton at mhsoftware.com (George Sexton) Date: Mon Feb 19 20:20:35 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <014c01c75482$31efa8a0$0202fea9@nigelhome> References: <014c01c75482$31efa8a0$0202fea9@nigelhome> Message-ID: <45DA76D5.1000307@mhsoftware.com> 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 > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From cyrus at daboo.name Mon Feb 19 20:43:01 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Feb 19 20:44:08 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <45DA76D5.1000307@mhsoftware.com> References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <45DA76D5.1000307@mhsoftware.com> Message-ID: <20ABEE9E3E9C98F6500E0900@ninevah.local> Hi George, --On February 19, 2007 9:19:33 PM -0700 George Sexton 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 From reinhold at kainhofer.com Mon Feb 19 22:38:03 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Mon Feb 19 22:39:13 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <014c01c75482$31efa8a0$0202fea9@nigelhome> References: <014c01c75482$31efa8a0$0202fea9@nigelhome> Message-ID: <200702200738.08127.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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) iD8DBQFF2pdQTqjEwhXvPN0RAuvxAJ0c/Z9B0McoiHq/p+Por95VZK7ibACcDXLC NY6IyvMHIhHcHyItDWJ3wcM= =VaNN -----END PGP SIGNATURE----- From Internet-Drafts at ietf.org Wed Feb 21 07:50:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Feb 21 07:51:04 2007 Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-03.txt Message-ID: 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 . The issue tracker for the Calsify WG is located at: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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. -------------- next part -------------- Skipped content of type multipart/alternative From Nigel.Swinson at rockliffe.com Wed Feb 21 09:06:33 2007 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Wed Feb 21 09:07:19 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <200702200738.08127.reinhold@kainhofer.com> Message-ID: <003401c755da$a43c3870$0202fea9@nigelhome> > 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. 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 From mikesamuel at gmail.com Wed Feb 21 12:55:43 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Wed Feb 21 12:56:44 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <003401c755da$a43c3870$0202fea9@nigelhome> References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <200702200738.08127.reinhold@kainhofer.com> <003401c755da$a43c3870$0202fea9@nigelhome> Message-ID: <178b8d440702211255y692fede8v3db5965a2f58763e@mail.gmail.com> On 21/02/07, Nigel Swinson 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 > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From mikesamuel at gmail.com Wed Feb 21 19:10:35 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Wed Feb 21 19:11:35 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <014c01c75482$31efa8a0$0202fea9@nigelhome> References: <014c01c75482$31efa8a0$0202fea9@nigelhome> Message-ID: <178b8d440702211910l1b7d0747sd85c86bbaa480cb1@mail.gmail.com> 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 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > From mikesamuel at gmail.com Wed Feb 21 19:16:23 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Wed Feb 21 19:17:21 2007 Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <178b8d440702211910l1b7d0747sd85c86bbaa480cb1@mail.gmail.com> References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <178b8d440702211910l1b7d0747sd85c86bbaa480cb1@mail.gmail.com> Message-ID: <178b8d440702211916s29817793s949ed8ce6ad3b832@mail.gmail.com> 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 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 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 > > _______________________________________________ > > Ietf-calsify mailing list > > Ietf-calsify@osafoundation.org > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > From alexey.melnikov at isode.com Thu Feb 22 04:46:48 2007 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Feb 22 05:36:00 2007 Subject: [Ietf-calsify] Section 3.2.8: Format Type ABNF Message-ID: <45DD90B8.7020504@isode.com> [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 /. 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 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. From alexey.melnikov at isode.com Thu Feb 22 04:47:13 2007 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Feb 22 05:36:03 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property Message-ID: <45DD90D1.4010509@isode.com> [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 @, 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 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. From alexey.melnikov at isode.com Thu Feb 22 04:51:41 2007 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Feb 22 05:36:04 2007 Subject: [Ietf-calsify] Question about section 3.1: name ABNF Message-ID: <45DD91DD.9090509@isode.com> >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? From alexey.melnikov at isode.com Thu Feb 22 04:56:54 2007 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Feb 22 05:36:04 2007 Subject: [Ietf-calsify] Use of URI parameters in ORGANIZER/ATTENDEE properties, DELEGATED-FROM parameter, etc. Message-ID: <45DD9316.4000103@isode.com> 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. From lear at cisco.com Thu Feb 22 06:56:04 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Feb 22 06:57:11 2007 Subject: [Ietf-calsify] jabber starts in 5 minutes! Message-ID: <45DDAF04.9070902@cisco.com> Server jabber.ietf.org, room calsify (calsify@jabber.ietf.org). Eliot From mgk at webfeet.co.uk Thu Feb 22 07:39:48 2007 From: mgk at webfeet.co.uk (Martin Kiff) Date: Thu Feb 22 07:40:55 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property In-Reply-To: <45DD90D1.4010509@isode.com> References: <45DD90D1.4010509@isode.com> Message-ID: <45DDB944.6060505@webfeet.co.uk> 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 From alexey.melnikov at isode.com Thu Feb 22 07:45:19 2007 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Feb 22 07:46:53 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property In-Reply-To: <45DDB944.6060505@webfeet.co.uk> References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> Message-ID: <45DDBA8F.50704@isode.com> 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. From cyrus at daboo.name Thu Feb 22 07:59:50 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Feb 22 08:00:57 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property In-Reply-To: <45DDB944.6060505@webfeet.co.uk> References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> Message-ID: <64F57A39D538EB4CDBFEEE89@caldav.apple.com> Hi Martin, --On February 22, 2007 4:39:48 PM +0100 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. 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 From mgk at webfeet.co.uk Thu Feb 22 22:51:48 2007 From: mgk at webfeet.co.uk (Martin Kiff) Date: Thu Feb 22 22:53:05 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property In-Reply-To: <64F57A39D538EB4CDBFEEE89@caldav.apple.com> References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> <64F57A39D538EB4CDBFEEE89@caldav.apple.com> Message-ID: <45DE8F04.6060806@webfeet.co.uk> Cyrus Daboo wrote: > Hi Martin, > > --On February 22, 2007 4:39:48 PM +0100 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. > > > 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 From TimHare at comcast.net Fri Feb 23 04:38:37 2007 From: TimHare at comcast.net (Tim Hare) Date: Fri Feb 23 04:41:26 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty In-Reply-To: <45DE8F04.6060806@webfeet.co.uk> Message-ID: <20070223124028.E853F14227B@laweleka.osafoundation.org> 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Martin Kiff Sent: Friday, February 23, 2007 1:52 AM To: Cyrus Daboo Cc: ietf-calsify@osafoundation.org 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 > 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From cyrus at daboo.name Fri Feb 23 07:08:43 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Fri Feb 23 07:09:50 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty In-Reply-To: <20070223124028.E853F14227B@laweleka.osafoundation.org> References: <20070223124028.E853F14227B@laweleka.osafoundation.org> Message-ID: <03081CF105D729594224FCAD@caldav.apple.com> Hi Tim, --On February 23, 2007 7:38:37 AM -0500 Tim Hare 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 lear at cisco.com Fri Feb 23 07:16:40 2007 From: lear at cisco.com (Eliot Lear) Date: Fri Feb 23 07:17:41 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty In-Reply-To: <03081CF105D729594224FCAD@caldav.apple.com> References: <20070223124028.E853F14227B@laweleka.osafoundation.org> <03081CF105D729594224FCAD@caldav.apple.com> Message-ID: <45DF0558.2040603@cisco.com> 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 > 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. > From lilmatt at mozilla.com Fri Feb 23 09:08:00 2007 From: lilmatt at mozilla.com (Matthew Willis) Date: Fri Feb 23 09:09:06 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property In-Reply-To: <45DDB944.6060505@webfeet.co.uk> References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> Message-ID: 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 From Bruce_Kahn at notesdev.ibm.com Fri Feb 23 09:21:12 2007 From: Bruce_Kahn at notesdev.ibm.com (Bruce Kahn) Date: Fri Feb 23 09:22:13 2007 Subject: Handling of DUE; VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] In-Reply-To: <45D9D2BB.3000803@oracle.com> References: <20070124040049.4044914221E@laweleka.osafoundation.org><45B6E39A.1010705@softdesign.net.nz><45B73E01.2070007@cisco.com><45B7CF12.3010109@oracle.com><45C7741C.8090608@oracle.com> <45D9D2BB.3000803@oracle.com> Message-ID: ietf-calsify-bounces@osafoundation.org 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 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. There are be different ways to express the same intent. If something has a due date of today then it I have until the end of the day to get it 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 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 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" one but perhaps that's just me. Bruce ========= ================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070223/cdd3d47f/attachment.htm From cyrus at daboo.name Sat Feb 24 07:58:46 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Sat Feb 24 07:59:50 2007 Subject: [Ietf-calsify] Wrong ABNF? Message-ID: <95AE3C39D949D9E9A9FC3512@ninevah.local> 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 From mgk at webfeet.co.uk Sat Feb 24 08:23:49 2007 From: mgk at webfeet.co.uk (Martin Kiff) Date: Sat Feb 24 08:25:02 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty In-Reply-To: <45DF0558.2040603@cisco.com> References: <20070223124028.E853F14227B@laweleka.osafoundation.org> <03081CF105D729594224FCAD@caldav.apple.com> <45DF0558.2040603@cisco.com> Message-ID: <45E06695.1090008@webfeet.co.uk> 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 From lear at cisco.com Sun Feb 25 11:02:39 2007 From: lear at cisco.com (Eliot Lear) Date: Sun Feb 25 11:03:48 2007 Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty In-Reply-To: <45E06695.1090008@webfeet.co.uk> References: <20070223124028.E853F14227B@laweleka.osafoundation.org> <03081CF105D729594224FCAD@caldav.apple.com> <45DF0558.2040603@cisco.com> <45E06695.1090008@webfeet.co.uk> Message-ID: <45E1DD4F.7000207@cisco.com> 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 From lear at cisco.com Mon Feb 26 02:36:49 2007 From: lear at cisco.com (Eliot Lear) Date: Mon Feb 26 02:37:52 2007 Subject: [Ietf-calsify] issue status for 2445bis Message-ID: <45E2B841.8010605@cisco.com> 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 notext 11 4 months ago Reinhold Kainhofer: additional examples, VTIMEZONEs, RRULEs notext 23 2 weeks ago Contradiction between UNTIL BNF rule and text Discuss 54 4 months ago Version value bump? unread 63 2 weeks ago Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART Discuss 67 2 weeks ago Section 4.8.2.5 Duration: VFREEBUSY request Discuss 68 2 weeks ago DST discontinuities part 1: date-times that fall in discontinutities notext 69 2 weeks ago DST discontinuities part 2: discontinuities for recurring event start times notext 70 2 weeks ago DST discontinuities part 3: discontinuities for event end times Discuss 71 2 weeks ago The "other" time discontinuity: leap-seconds Discuss 72 2 weeks ago Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE Discuss 73 2 weeks ago Section 4.8.3.1 Time Zone Identifier: Scope of TZID] Discuss 78 4 days ago Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM Discuss 79 4 days ago Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? Discuss 8 4 months ago Reinhold Kainhofer: Deprecate P1D or P24H? notext -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070226/ccf405e9/attachment.htm From cmtalbert at gmail.com Mon Feb 26 05:13:44 2007 From: cmtalbert at gmail.com (Clint Talbert) Date: Mon Feb 26 05:14:46 2007 Subject: [Ietf-calsify] issue status for 2445bis In-Reply-To: <45E2B841.8010605@cisco.com> References: <45E2B841.8010605@cisco.com> Message-ID: <45E2DD08.4030704@gmail.com> Hello all, I'm a bit confused by Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE . 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 > notext > 11 4 months ago Reinhold Kainhofer: additional examples, VTIMEZONEs, > RRULEs > notext > 23 2 weeks ago Contradiction between UNTIL BNF rule and text > Discuss > 54 4 months ago Version value bump? > unread > 63 2 weeks ago Section 4.8.5.3 Recurrence Date/Times: RDATE < > DTSTART > Discuss > 67 2 weeks ago Section 4.8.2.5 Duration: VFREEBUSY request > Discuss > 68 2 weeks ago DST discontinuities part 1: date-times that fall in > discontinutities > notext > 69 2 weeks ago DST discontinuities part 2: discontinuities for > recurring event start times > notext > 70 2 weeks ago DST discontinuities part 3: discontinuities for event > end times > Discuss > 71 2 weeks ago The "other" time discontinuity: leap-seconds > Discuss > 72 2 weeks ago Section 4.6.5 Time Zone Component: Not required when > DTSTART is a DATE > Discuss > 73 2 weeks ago Section 4.8.3.1 Time Zone Identifier: Scope of TZID] > Discuss > 78 4 days ago Section 4.6.5 Time Zone Component: DTSTART with > TZOFFSETFROM > Discuss > 79 4 days ago Section 4.6.5 Time Zone Component: DTSTART always an > onset date-time of an observance? > Discuss > 8 4 months ago Reinhold Kainhofer: Deprecate P1D or P24H? > notext > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070226/0b36f8b3/attachment.html From batsonjay at plumcanary.com Mon Feb 26 05:22:17 2007 From: batsonjay at plumcanary.com (Jay Batson) Date: Mon Feb 26 05:23:58 2007 Subject: [Ietf-calsify] Issues with Security / Spoofing section Message-ID: <6E8D487F-C9BF-4C88-9BDF-D07D5B3AD2A3@plumcanary.com> 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 batsonjay@plumcanary.com +1-978-824-0111 (w) +1-978-758-1599 (m) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070226/823776ee/attachment-0001.htm From lear at cisco.com Mon Feb 26 07:54:46 2007 From: lear at cisco.com (Eliot Lear) Date: Mon Feb 26 07:55:47 2007 Subject: [Ietf-calsify] issue status for 2445bis In-Reply-To: <45E2DD08.4030704@gmail.com> References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> Message-ID: <45E302C6.9070200@cisco.com> 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 > . > 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 From cmtalbert at gmail.com Mon Feb 26 08:29:42 2007 From: cmtalbert at gmail.com (Clint Talbert) Date: Mon Feb 26 08:30:44 2007 Subject: [Ietf-calsify] issue status for 2445bis In-Reply-To: <45E302C6.9070200@cisco.com> References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> <45E302C6.9070200@cisco.com> Message-ID: <45E30AF6.3030506@gmail.com> 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 >> . >> 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 From bernard.desruisseaux at oracle.com Mon Feb 26 10:44:39 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Feb 26 10:46:04 2007 Subject: [Ietf-calsify] Wrong ABNF? In-Reply-To: <95AE3C39D949D9E9A9FC3512@ninevah.local> References: <95AE3C39D949D9E9A9FC3512@ninevah.local> Message-ID: <45E32A97.8050500@oracle.com> 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. > From bernard.desruisseaux at oracle.com Mon Feb 26 11:45:57 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Feb 26 11:47:16 2007 Subject: Issue 72: Re: [Ietf-calsify] issue status for 2445bis In-Reply-To: <45E30AF6.3030506@gmail.com> References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> <45E302C6.9070200@cisco.com> <45E30AF6.3030506@gmail.com> Message-ID: <45E338F5.6090502@oracle.com> 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 >>> . >>> 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From cmtalbert at gmail.com Mon Feb 26 13:55:20 2007 From: cmtalbert at gmail.com (Clint Talbert) Date: Mon Feb 26 13:56:19 2007 Subject: Issue 72: Re: [Ietf-calsify] issue status for 2445bis In-Reply-To: <45E338F5.6090502@oracle.com> References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> <45E302C6.9070200@cisco.com> <45E30AF6.3030506@gmail.com> <45E338F5.6090502@oracle.com> Message-ID: <45E35748.2050307@gmail.com> 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 From lear at cisco.com Wed Feb 28 04:41:53 2007 From: lear at cisco.com (Eliot Lear) Date: Wed Feb 28 04:42:56 2007 Subject: [Ietf-calsify] Disposition of Various Issues Message-ID: <45E57891.4050906@cisco.com> $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 Wed Feb 28 05:09:28 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Wed Feb 28 05:10:36 2007 Subject: [Ietf-calsify] Disposition of Various Issues In-Reply-To: <45E57891.4050906@cisco.com> References: <45E57891.4050906@cisco.com> Message-ID: <200702281409.29449.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 28. Februar 2007 schrieb Eliot Lear: > $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. 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: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF5X8JTqjEwhXvPN0RAj+iAJ4wCcD/swEQBQ0lyYf5st4niqNbggCeOowG oPoiW7k+EMY2vC30pQqhWWA= =PG+Q -----END PGP SIGNATURE----- From cyrus at daboo.name Wed Feb 28 07:46:17 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed Feb 28 07:47:27 2007 Subject: [Ietf-calsify] More references to 2446? Message-ID: <6D5501105973FF4008DD13E0@caldav.apple.com> 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 lear at cisco.com Wed Feb 28 10:17:46 2007 From: lear at cisco.com (Eliot Lear) Date: Wed Feb 28 10:18:54 2007 Subject: [Ietf-calsify] Disposition of Various Issues In-Reply-To: <200702281409.29449.reinhold@kainhofer.com> References: <45E57891.4050906@cisco.com> <200702281409.29449.reinhold@kainhofer.com> Message-ID: <45E5C74A.6000602@cisco.com> 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 > > Am Mittwoch, 28. Februar 2007 schrieb Eliot Lear: > >> $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. >> > > 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: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ > * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ > * K Desktop Environment, http://www.kde.org, KOrganizer maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFF5X8JTqjEwhXvPN0RAj+iAJ4wCcD/swEQBQ0lyYf5st4niqNbggCeOowG > oPoiW7k+EMY2vC30pQqhWWA= > =PG+Q > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > From lennox at cs.columbia.edu Wed Feb 28 13:08:50 2007 From: lennox at cs.columbia.edu (Jonathan Lennox) Date: Wed Feb 28 13:10:02 2007 Subject: DST discontinuities (was Re: [Ietf-calsify] Disposition of Various Issues) In-Reply-To: <45E57891.4050906@cisco.com> References: <45E57891.4050906@cisco.com> Message-ID: <17893.61282.676928.454073@metro-north.cs.columbia.edu> On Wednesday, February 28 2007, "Eliot Lear" wrote to "ietf-calsify@osafoundation.org" saying: > Issues 68, 69: DST discontinuities > > No text has been received. These issues will be closed without change > barring objection. 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 lennox@cs.columbia.edu From Nigel.Swinson at rockliffe.com Wed Feb 28 15:42:46 2007 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Wed Feb 28 15:43:09 2007 Subject: DST discontinuities (was Re: [Ietf-calsify] Disposition of VariousIssues) References: <45E57891.4050906@cisco.com> <17893.61282.676928.454073@metro-north.cs.columbia.edu> Message-ID: <00ab01c75b92$27523400$d201a8c0@nigelhome> > 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. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5B4F07FA6C for ; Wed, 28 Feb 2007 15:43:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D5278142264 for ; Wed, 28 Feb 2007 15:42:12 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27065-09 for ; Wed, 28 Feb 2007 15:42:12 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 72E3F142262 for ; Wed, 28 Feb 2007 15:42:12 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 2054ec0381699b4fd5541b7dcbd200b9 X-Spam-Score-Summary: 2, 0, 0, 7674dd8417f91f8c, 274b843a5d0108d0, nigel.swinson@rockliffe.com, , 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 X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 28 Feb 2007 15:42:11 -0800 Message-ID: <00ab01c75b92$27523400$d201a8c0@nigelhome> From: "Nigel Swinson" To: "Jonathan Lennox" References: <45E57891.4050906@cisco.com> <17893.61282.676928.454073@metro-north.cs.columbia.edu> Subject: Re: DST discontinuities (was Re: [Ietf-calsify] Disposition of VariousIssues) Date: Wed, 28 Feb 2007 23:42:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 23:43:07 -0000 > 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 > would occur take place over the intervals >=20 > 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 >=20 > always, for every time zone. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 06E8C7F635 for ; Wed, 28 Feb 2007 13:09:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0286D142264 for ; Wed, 28 Feb 2007 13:09:05 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25354-03 for ; Wed, 28 Feb 2007 13:09:04 -0800 (PST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 62CA914225E for ; Wed, 28 Feb 2007 13:09:04 -0800 (PST) Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l1SL913h016804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Feb 2007 16:09:02 -0500 (EST) Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l1SL91xn004787 for ; Wed, 28 Feb 2007 16:09:01 -0500 (EST) Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id l1SL8oM4004784; Wed, 28 Feb 2007 16:08:50 -0500 (EST) X-Authentication-Warning: metro-north.cs.columbia.edu: lennox set sender to lennox@cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17893.61282.676928.454073@metro-north.cs.columbia.edu> Date: Wed, 28 Feb 2007 16:08:50 -0500 To: "ietf-calsify@osafoundation.org" Subject: DST discontinuities (was Re: [Ietf-calsify] Disposition of Various Issues) In-Reply-To: <45E57891.4050906@cisco.com> References: <45E57891.4050906@cisco.com> X-Mailer: VM 7.19 under Emacs 20.7.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 21:10:00 -0000 On Wednesday, February 28 2007, "Eliot Lear" wrote to "ietf-calsify@osafoundation.org" saying: > Issues 68, 69: DST discontinuities > > No text has been received. These issues will be closed without change > barring objection. 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 lennox@cs.columbia.edu Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3030E7F9EA for ; Wed, 28 Feb 2007 10:18:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AA54414225B for ; Wed, 28 Feb 2007 10:17:57 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22057-07 for ; Wed, 28 Feb 2007 10:17:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id A3956142258 for ; Wed, 28 Feb 2007 10:17:55 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Feb 2007 19:17:55 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1SIHsJK001851; Wed, 28 Feb 2007 19:17:54 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp85.cisco.com [10.61.64.85]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1SIHkC8011785; Wed, 28 Feb 2007 19:17:51 +0100 (MET) Message-ID: <45E5C74A.6000602@cisco.com> Date: Wed, 28 Feb 2007 19:17:46 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Reinhold Kainhofer Subject: Re: [Ietf-calsify] Disposition of Various Issues References: <45E57891.4050906@cisco.com> <200702281409.29449.reinhold@kainhofer.com> In-Reply-To: <200702281409.29449.reinhold@kainhofer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3500; t=1172686674; x=1173550674; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20Disposition=20of=20Various=20Issues |Sender:=20; bh=/G0kJ1dCiGm3Gq3LcbifS4aJGhV4ZF/9g4v9hcUIY/I=; b=ObvQRTPWvn3M6WKHYspojjFIZ4UCxUPRa16oSNbMJZw1Gzz8pRD+pZmbwYvQ2pf0e0VvOTFC ebfG3GMbQgzAGk+C8MiT7IPRjJY7TcqgJFaGARuz6bE7YJ7T+ZPg4R1U; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 18:18:52 -0000 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 > > Am Mittwoch, 28. Februar 2007 schrieb Eliot Lear: > >> $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. >> > > 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: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ > * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ > * K Desktop Environment, http://www.kde.org, KOrganizer maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFF5X8JTqjEwhXvPN0RAj+iAJ4wCcD/swEQBQ0lyYf5st4niqNbggCeOowG > oPoiW7k+EMY2vC30pQqhWWA= > =PG+Q > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DAEAF7F9A2 for ; Wed, 28 Feb 2007 07:47:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6253A142250 for ; Wed, 28 Feb 2007 07:46:30 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19178-06 for ; Wed, 28 Feb 2007 07:46:29 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 718B614224B for ; Wed, 28 Feb 2007 07:46:29 -0800 (PST) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1SFkM60011791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Feb 2007 10:46:25 -0500 Date: Wed, 28 Feb 2007 10:46:17 -0500 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: <6D5501105973FF4008DD13E0@caldav.apple.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, MISSING_SUBJECT X-Spam-Level: Subject: [Ietf-calsify] More references to 2446? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 15:47:25 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id ABD417F537 for ; Wed, 28 Feb 2007 05:10:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1516214225D for ; Wed, 28 Feb 2007 05:09:40 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12107-04 for ; Wed, 28 Feb 2007 05:09:38 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 379F1142257 for ; Wed, 28 Feb 2007 05:09:37 -0800 (PST) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1SD9UIb007945 for ; Wed, 28 Feb 2007 14:09:33 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Disposition of Various Issues Date: Wed, 28 Feb 2007 14:09:28 +0100 User-Agent: KMail/1.9.5 + Features References: <45E57891.4050906@cisco.com> In-Reply-To: <45E57891.4050906@cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702281409.29449.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 13:10:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 28. Februar 2007 schrieb Eliot Lear: > $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. 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: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF5X8JTqjEwhXvPN0RAj+iAJ4wCcD/swEQBQ0lyYf5st4niqNbggCeOowG oPoiW7k+EMY2vC30pQqhWWA= =PG+Q -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 381477F5F8 for ; Wed, 28 Feb 2007 04:42:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B354A14225D for ; Wed, 28 Feb 2007 04:42:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10091-07 for ; Wed, 28 Feb 2007 04:42:00 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F5E714224C for ; Wed, 28 Feb 2007 04:42:00 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2007 04:41:59 -0800 X-IronPort-AV: i="4.14,230,1170662400"; d="scan'208"; a="764826985:sNHT42108600" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1SCfw42012427 for ; Wed, 28 Feb 2007 13:41:58 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4265.cisco.com [10.61.80.168]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1SCfsC8029639 for ; Wed, 28 Feb 2007 13:41:58 +0100 (MET) Message-ID: <45E57891.4050906@cisco.com> Date: Wed, 28 Feb 2007 13:41:53 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1322; t=1172666518; x=1173530518; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Disposition=20of=20Various=20Issues |Sender:=20; bh=FKQTJs12FrsSFXNQH8u7a+xMUv09TnNjV2lgGdH0JgA=; b=nzFppWiI+grh03XAiaTqqe7xR2gi0bb3Z58Otz1NOjd03xPT1L7ADSX8sgXSi2hNliech3AM IC6/rxmE4ifD+5e3mmvuqPbb3tCUuFtIzHDqf54NOQV5GiVqzC53jY1L; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Subject: [Ietf-calsify] Disposition of Various Issues X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 12:42:55 -0000 $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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BD7EF7F67E for ; Mon, 26 Feb 2007 13:56:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4491B142267 for ; Mon, 26 Feb 2007 13:55:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15829-08 for ; Mon, 26 Feb 2007 13:55:23 -0800 (PST) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9CEEB14225D for ; Mon, 26 Feb 2007 13:55:23 -0800 (PST) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id DD1A21E1096; Mon, 26 Feb 2007 16:55:22 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 26 Feb 2007 16:55:22 -0500 X-Sasl-enc: /0TqTcDAva8KqQos4XsmqVJFezjQfLbNvigpDsJk5Qx9 1172526922 Received: from clint-talberts-powerbook-g4-12.local (rrcs-67-79-207-178.sw.biz.rr.com [67.79.207.178]) by mail.messagingengine.com (Postfix) with ESMTP id 314411A172; Mon, 26 Feb 2007 16:55:22 -0500 (EST) Message-ID: <45E35748.2050307@gmail.com> Date: Mon, 26 Feb 2007 15:55:20 -0600 From: Clint Talbert User-Agent: Thunderbird 2.0pre (Macintosh/20070221) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: Issue 72: Re: [Ietf-calsify] issue status for 2445bis References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> <45E302C6.9070200@cisco.com> <45E30AF6.3030506@gmail.com> <45E338F5.6090502@oracle.com> In-Reply-To: <45E338F5.6090502@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.1 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: * Cc: "ietf-calsify@osafoundation.org" X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 21:56:19 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1F2DF7FD08 for ; Mon, 26 Feb 2007 11:47:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9576314226C for ; Mon, 26 Feb 2007 11:46:20 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13397-09 for ; Mon, 26 Feb 2007 11:46:19 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F1D0F142260 for ; Mon, 26 Feb 2007 11:46:17 -0800 (PST) Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1QJkEU0011037; Mon, 26 Feb 2007 13:46:14 -0600 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1QHsfmr012897; Mon, 26 Feb 2007 12:46:11 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2478847521172519155; Mon, 26 Feb 2007 12:45:55 -0700 Message-ID: <45E338F5.6090502@oracle.com> Date: Mon, 26 Feb 2007 14:45:57 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Clint Talbert , Eliot Lear Subject: Issue 72: Re: [Ietf-calsify] issue status for 2445bis References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> <45E302C6.9070200@cisco.com> <45E30AF6.3030506@gmail.com> In-Reply-To: <45E30AF6.3030506@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: "ietf-calsify@osafoundation.org" X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 19:47:15 -0000 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 >>> . >>> 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E4E507F9EA for ; Mon, 26 Feb 2007 10:46:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E90214226E for ; Mon, 26 Feb 2007 10:45:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11672-07 for ; Mon, 26 Feb 2007 10:45:08 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E5113142267 for ; Mon, 26 Feb 2007 10:45:07 -0800 (PST) Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l1QIirw0031822; Mon, 26 Feb 2007 11:44:54 -0700 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1QHI6Er031150; Mon, 26 Feb 2007 11:44:53 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2478736191172515477; Mon, 26 Feb 2007 11:44:37 -0700 Message-ID: <45E32A97.8050500@oracle.com> Date: Mon, 26 Feb 2007 13:44:39 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Wrong ABNF? References: <95AE3C39D949D9E9A9FC3512@ninevah.local> In-Reply-To: <95AE3C39D949D9E9A9FC3512@ninevah.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 18:46:03 -0000 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. > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 922727FA2F for ; Mon, 26 Feb 2007 08:30:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1AFA0142249 for ; Mon, 26 Feb 2007 08:29:48 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09129-06 for ; Mon, 26 Feb 2007 08:29:45 -0800 (PST) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by laweleka.osafoundation.org (Postfix) with ESMTP id 952AA142267 for ; Mon, 26 Feb 2007 08:29:45 -0800 (PST) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 0B3471D934E for ; Mon, 26 Feb 2007 11:29:45 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 26 Feb 2007 11:29:45 -0500 X-Sasl-enc: OD6vfPQfU1d+KIbXDaDpj0EQjbskGkSp2981Vl8HIOtb 1172507384 Received: from clint-talberts-powerbook-g4-12.local (rrcs-67-79-207-178.sw.biz.rr.com [67.79.207.178]) by mail.messagingengine.com (Postfix) with ESMTP id 9B93F17C16 for ; Mon, 26 Feb 2007 11:29:44 -0500 (EST) Message-ID: <45E30AF6.3030506@gmail.com> Date: Mon, 26 Feb 2007 10:29:42 -0600 From: Clint Talbert User-Agent: Thunderbird 2.0pre (Macintosh/20070221) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Subject: Re: [Ietf-calsify] issue status for 2445bis References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> <45E302C6.9070200@cisco.com> In-Reply-To: <45E302C6.9070200@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.0 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 16:30:42 -0000 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 >> . >> 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 292BF7FA9C for ; Mon, 26 Feb 2007 07:55:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A751714226D for ; Mon, 26 Feb 2007 07:54:50 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11317-01 for ; Mon, 26 Feb 2007 07:54:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id E64C4142258 for ; Mon, 26 Feb 2007 07:54:48 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2007 16:54:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QFsljT012515; Mon, 26 Feb 2007 16:54:47 +0100 Received: from elear-mac.cisco.com (dhcp-wdata-vlan18-22-220.cisco.com [144.254.22.220]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QFslC8018482; Mon, 26 Feb 2007 16:54:47 +0100 (MET) Message-ID: <45E302C6.9070200@cisco.com> Date: Mon, 26 Feb 2007 16:54:46 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Clint Talbert Subject: Re: [Ietf-calsify] issue status for 2445bis References: <45E2B841.8010605@cisco.com> <45E2DD08.4030704@gmail.com> In-Reply-To: <45E2DD08.4030704@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=454; t=1172505287; x=1173369287; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20issue=20status=20for=202445bis |Sender:=20; bh=8HpXTjBIYhvrf17LhNwy+NyfIXa2Rr1ydGvnXAM+uDU=; b=DiIkaaFU1t85bnmIzM8ECggQU9uA4pywPuBFK2Nfd5r39EeEXFqCksddz/lF+6wkWwkO2RBc yC1zqhMKn3tO5t4b1JphN66w+KEQrxpzh9Mh0bFpmhVj3hTkJdyuzT6S; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: "ietf-calsify@osafoundation.org" X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 15:55:45 -0000 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 > . > 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 Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 85B9B7F999 for ; Mon, 26 Feb 2007 05:23:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0F65014227B for ; Mon, 26 Feb 2007 05:23:02 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07632-06 for ; Mon, 26 Feb 2007 05:23:01 -0800 (PST) Received: from plumcanary.com (mail.plumcanary.com [216.154.222.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D3138142279 for ; Mon, 26 Feb 2007 05:23:00 -0800 (PST) Received: from [192.168.1.109] (c-24-61-128-135.hsd1.ma.comcast.net [24.61.128.135]) by plumcanary.com (8.12.11.20060308/8.12.11) with ESMTP id l1QDMJXI015978 for ; Mon, 26 Feb 2007 08:22:59 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: Calsify WG Message-Id: <6E8D487F-C9BF-4C88-9BDF-D07D5B3AD2A3@plumcanary.com> Content-Type: multipart/alternative; boundary=Apple-Mail-24-915409424 From: Jay Batson Date: Mon, 26 Feb 2007 08:22:17 -0500 X-Mailer: Apple Mail (2.752.2) Received-SPF: softfail (plumcanary.com: domain of transitioning batsonjay@plumcanary.com does not designate 24.61.128.135 as permitted sender) receiver=plumcanary.com; client-ip=24.61.128.135; helo=[192.168.1.109]; envelope-from=batsonjay@plumcanary.com; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf2-1.0.0; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_MESSAGE, MISSING_SUBJECT X-Spam-Level: Subject: [Ietf-calsify] Issues with Security / Spoofing section X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 13:23:56 -0000 --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 batsonjay@plumcanary.com +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
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.=A0 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.=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.

ILLUSTRATIVE = BACKGROUND:
Assume:
-=A0a 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.=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.

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.

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.

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

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

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

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.

Comments?
-jb
=
batsonjay@plumcanary.com
+1-978-824-0111 (w)
+1-978-758-1599 (m)

= --Apple-Mail-24-915409424-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A345E7F956 for ; Mon, 26 Feb 2007 05:14:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2BC8014227B for ; Mon, 26 Feb 2007 05:13:50 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05644-09 for ; Mon, 26 Feb 2007 05:13:48 -0800 (PST) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by laweleka.osafoundation.org (Postfix) with ESMTP id EB782142279 for ; Mon, 26 Feb 2007 05:13:47 -0800 (PST) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 180671D3878; Mon, 26 Feb 2007 08:13:47 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 26 Feb 2007 08:13:47 -0500 X-Sasl-enc: PVC6QuAdazrt3UCTMq+xHQZCMLVen10/4Fp32+3sKryf 1172495626 Received: from clint-talberts-powerbook-g4-12.local (rrcs-67-79-207-178.sw.biz.rr.com [67.79.207.178]) by mail.messagingengine.com (Postfix) with ESMTP id 34C961D28F; Mon, 26 Feb 2007 08:13:46 -0500 (EST) Message-ID: <45E2DD08.4030704@gmail.com> Date: Mon, 26 Feb 2007 07:13:44 -0600 From: Clint Talbert User-Agent: Thunderbird 2.0pre (Macintosh/20070221) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] issue status for 2445bis References: <45E2B841.8010605@cisco.com> In-Reply-To: <45E2B841.8010605@cisco.com> Content-Type: multipart/alternative; boundary="------------080208030806070804020209" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, HTML_50_60, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, MISSING_SUBJECT X-Spam-Level: Cc: "ietf-calsify@osafoundation.org" X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 13:14:44 -0000 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 . 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 > notext > 11 4 months ago Reinhold Kainhofer: additional examples, VTIMEZONEs, > RRULEs > notext > 23 2 weeks ago Contradiction between UNTIL BNF rule and text > Discuss > 54 4 months ago Version value bump? > unread > 63 2 weeks ago Section 4.8.5.3 Recurrence Date/Times: RDATE < > DTSTART > Discuss > 67 2 weeks ago Section 4.8.2.5 Duration: VFREEBUSY request > Discuss > 68 2 weeks ago DST discontinuities part 1: date-times that fall in > discontinutities > notext > 69 2 weeks ago DST discontinuities part 2: discontinuities for > recurring event start times > notext > 70 2 weeks ago DST discontinuities part 3: discontinuities for event > end times > Discuss > 71 2 weeks ago The "other" time discontinuity: leap-seconds > Discuss > 72 2 weeks ago Section 4.6.5 Time Zone Component: Not required when > DTSTART is a DATE > Discuss > 73 2 weeks ago Section 4.8.3.1 Time Zone Identifier: Scope of TZID] > Discuss > 78 4 days ago Section 4.6.5 Time Zone Component: DTSTART with > TZOFFSETFROM > Discuss > 79 4 days ago Section 4.6.5 Time Zone Component: DTSTART always an > onset date-time of an observance? > Discuss > 8 4 months ago Reinhold Kainhofer: Deprecate P1D or P24H? > notext > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > --------------080208030806070804020209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

I'm a bit confused by Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE.  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 notext
11 4 months ago Reinhold Kainhofer: additional examples, VTIMEZONEs, RRULEs notext
23 2 weeks ago Contradiction between UNTIL BNF rule and text Discuss
54 4 months ago Version value bump? unread
63 2 weeks ago Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART Discuss
67 2 weeks ago Section 4.8.2.5 Duration: VFREEBUSY request Discuss
68 2 weeks ago DST discontinuities part 1: date-times that fall in discontinutities notext
69 2 weeks ago DST discontinuities part 2: discontinuities for recurring event start times notext
70 2 weeks ago DST discontinuities part 3: discontinuities for event end times Discuss
71 2 weeks ago The "other" time discontinuity: leap-seconds Discuss
72 2 weeks ago Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE Discuss
73 2 weeks ago Section 4.8.3.1 Time Zone Identifier: Scope of TZID] Discuss
78 4 days ago Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM Discuss
79 4 days ago Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? Discuss
8 4 months ago Reinhold Kainhofer: Deprecate P1D or P24H? notext 


_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--------------080208030806070804020209-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B61127F98E for ; Mon, 26 Feb 2007 02:37:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 37F0414227D for ; Mon, 26 Feb 2007 02:36:56 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06289-07 for ; Mon, 26 Feb 2007 02:36:54 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id CE6F614227C for ; Mon, 26 Feb 2007 02:36:53 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2007 11:36:53 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QAaqlE009807 for ; Mon, 26 Feb 2007 11:36:52 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp549.cisco.com [10.61.66.37]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QAanC8016550 for ; Mon, 26 Feb 2007 11:36:52 +0100 (MET) Message-ID: <45E2B841.8010605@cisco.com> Date: Mon, 26 Feb 2007 11:36:49 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: multipart/alternative; boundary="------------020709020603080908070103" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8521; t=1172486212; x=1173350212; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20issue=20status=20for=202445bis |Sender:=20; bh=oK8KxxWNpYVxg4/Di296TPKFNNMAmbCWBIohNzcO1tU=; b=bR4yIBiqMBHU29eNGpAV2fApLNSMfTgdojcwF13QC8wBkqu+cEIJ3E6kvoG2o7YU6xs2g59u wWjCnWwCjvYMzPLWaVL+0E9D8a/BeYEYTTT1sAd3LDGtaUEvfqZKy1Aw; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, MISSING_SUBJECT X-Spam-Level: Subject: [Ietf-calsify] issue status for 2445bis X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 10:37:50 -0000 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 notext 11 4 months ago Reinhold Kainhofer: additional examples, VTIMEZONEs, RRULEs notext 23 2 weeks ago Contradiction between UNTIL BNF rule and text Discuss 54 4 months ago Version value bump? unread 63 2 weeks ago Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART Discuss 67 2 weeks ago Section 4.8.2.5 Duration: VFREEBUSY request Discuss 68 2 weeks ago DST discontinuities part 1: date-times that fall in discontinutities notext 69 2 weeks ago DST discontinuities part 2: discontinuities for recurring event start times notext 70 2 weeks ago DST discontinuities part 3: discontinuities for event end times Discuss 71 2 weeks ago The "other" time discontinuity: leap-seconds Discuss 72 2 weeks ago Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE Discuss 73 2 weeks ago Section 4.8.3.1 Time Zone Identifier: Scope of TZID] Discuss 78 4 days ago Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM Discuss 79 4 days ago Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? Discuss 8 4 months ago Reinhold Kainhofer: Deprecate P1D or P24H? notext --------------020709020603080908070103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 notext
11 4 months ago Reinhold Kainhofer: additional examples, VTIMEZONEs, RRULEs notext
23 2 weeks ago Contradiction between UNTIL BNF rule and text Discuss
54 4 months ago Version value bump? unread
63 2 weeks ago Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART Discuss
67 2 weeks ago Section 4.8.2.5 Duration: VFREEBUSY request Discuss
68 2 weeks ago DST discontinuities part 1: date-times that fall in discontinutities notext
69 2 weeks ago DST discontinuities part 2: discontinuities for recurring event start times notext
70 2 weeks ago DST discontinuities part 3: discontinuities for event end times Discuss
71 2 weeks ago The "other" time discontinuity: leap-seconds Discuss
72 2 weeks ago Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE Discuss
73 2 weeks ago Section 4.8.3.1 Time Zone Identifier: Scope of TZID] Discuss
78 4 days ago Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM Discuss
79 4 days ago Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? Discuss
8 4 months ago Reinhold Kainhofer: Deprecate P1D or P24H? notext

--------------020709020603080908070103-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6DDF97FAC0 for ; Sun, 25 Feb 2007 11:03:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EBEAC14227B for ; Sun, 25 Feb 2007 11:02:51 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30986-10 for ; Sun, 25 Feb 2007 11:02:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 47DAD142270 for ; Sun, 25 Feb 2007 11:02:51 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Feb 2007 20:02:50 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1PJ2owq022109; Sun, 25 Feb 2007 20:02:50 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp549.cisco.com [10.61.66.37]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1PJ2hC8002853; Sun, 25 Feb 2007 20:02:48 +0100 (MET) Message-ID: <45E1DD4F.7000207@cisco.com> Date: Sun, 25 Feb 2007 20:02:39 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Martin Kiff Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty References: <20070223124028.E853F14227B@laweleka.osafoundation.org> <03081CF105D729594224FCAD@caldav.apple.com> <45DF0558.2040603@cisco.com> <45E06695.1090008@webfeet.co.uk> In-Reply-To: <45E06695.1090008@webfeet.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=242; t=1172430170; x=1173294170; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20Section=203.8.4.7=3A=20Recommended=2 0syntax=09for=09the=09UIDproperty |Sender:=20; bh=pGdnAWryOKVBQX4d6gw6JKIQ5Sjj2WWP58CmKFmY6Fs=; b=Q7NsjiPGbqUjhsdt2ShysFnbVKFNvN4zUQDKLMQli2d4WVeVauGUEcnyub3pmUZq++kz4NwB gkJyQg4y8HqnFe+uKWpDQczm2gGlAH0N9z9wYIwZj07jVOSYNhhphImp; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 19:03:46 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4A96E7FDB9 for ; Sat, 24 Feb 2007 08:25:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C93DB14227A for ; Sat, 24 Feb 2007 08:24:06 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31269-10 for ; Sat, 24 Feb 2007 08:24:06 -0800 (PST) Received: from mail.zserv.tuwien.ac.at (mail.zserv.tuwien.ac.at [128.130.35.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1125A142278 for ; Sat, 24 Feb 2007 08:24:05 -0800 (PST) Received: from [192.168.0.101] (v226-019.vpm.tuwien.ac.at [128.131.226.19]) by mail.zserv.tuwien.ac.at (@(#)Sendmail version 8.13.3 - Revision 1.003 - 05/24/2006/8.13.1) with ESMTP id l1OGNnwZ007189; Sat, 24 Feb 2007 17:23:49 +0100 (MEZ) Message-ID: <45E06695.1090008@webfeet.co.uk> Date: Sat, 24 Feb 2007 17:23:49 +0100 From: Martin Kiff User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty References: <20070223124028.E853F14227B@laweleka.osafoundation.org> <03081CF105D729594224FCAD@caldav.apple.com> <45DF0558.2040603@cisco.com> In-Reply-To: <45DF0558.2040603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 16:25:01 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EAD987FBA4 for ; Sat, 24 Feb 2007 07:59:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 770BE142277 for ; Sat, 24 Feb 2007 07:58:54 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00457-10 for ; Sat, 24 Feb 2007 07:58:53 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 91C4D142276 for ; Sat, 24 Feb 2007 07:58:53 -0800 (PST) Received: from [10.0.1.5] ([10.0.1.5]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1OFwkbs015215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 24 Feb 2007 10:58:50 -0500 Date: Sat, 24 Feb 2007 10:58:46 -0500 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: <95AE3C39D949D9E9A9FC3512@ninevah.local> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, MISSING_SUBJECT X-Spam-Level: Subject: [Ietf-calsify] Wrong ABNF? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 15:59:49 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2FE3C80443 for ; Fri, 23 Feb 2007 09:22:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AF268142276 for ; Fri, 23 Feb 2007 09:21:16 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13083-05 for ; Fri, 23 Feb 2007 09:21:16 -0800 (PST) Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id D5B17142274 for ; Fri, 23 Feb 2007 09:21:15 -0800 (PST) In-Reply-To: <45D9D2BB.3000803@oracle.com> To: Bernard Desruisseaux Subject: Re: Handling of DUE; VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] Message-ID: Date: Fri, 23 Feb 2007 12:21:12 -0500 From: "Bruce Kahn" Content-Type: multipart/alternative; boundary="=_alternative 005F28B48525728B_=" References: <20070124040049.4044914221E@laweleka.osafoundation.org><45B6E39A.1010705@softdesign.net.nz><45B73E01.2070007@cisco.com><45B7CF12.3010109@oracle.com><45C7741C.8090608@oracle.com> <45D9D2BB.3000803@oracle.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Build V80_02122007NP February 12, 2007 X-Disclaimed: 9771 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.2 tagged_above=-50.0 required=4.0 tests=HTML_30_40, HTML_MESSAGE, MISSING_SUBJECT X-Spam-Level: * Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 17:22:11 -0000 --=_alternative 005F28B48525728B_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable ietf-calsify-bounces@osafoundation.org 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=5FKahn@notesdev.ibm.com 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
ietf-calsify-bounces@osafoundation.org wrote on 02/1= 9/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 sa= me 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 Febu= rary 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 pr= esenting
> this value as "Due by" to avoid this ambiguity.<= br>
  There are be d= ifferent ways to express the same intent.  If something has a due date of today then it I have until the end of the day to get it 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 as long as you can clear= ly and consistently express the correct intent.  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.

  I find that a "due by" meaning is much less ambiguous then a "due date" 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     &nbs= p;                          INet: Bruce=5FKahn@notesdev= .ibm.com
Messaging & Collaboration          = ;       Phone: 978.399.6496
IBM Software Group      = ;                   FAX: and nothing but the FAX...
Once you mak= e something idiot-proof, they build a better idiot.

--=_alternative 005F28B48525728B_=-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1A6F57FB56 for ; Fri, 23 Feb 2007 09:09:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9A6B6142276 for ; Fri, 23 Feb 2007 09:08:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13600-07 for ; Fri, 23 Feb 2007 09:08:10 -0800 (PST) Received: from dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3CB35142274 for ; Fri, 23 Feb 2007 09:08:10 -0800 (PST) Received: from [10.0.1.5] (cpe-24-59-111-31.twcny.res.rr.com [24.59.111.31]) (Authenticated sender: mwillis@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id BE01F6A9342 for ; Fri, 23 Feb 2007 09:08:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45DDB944.6060505@webfeet.co.uk> References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matthew Willis 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: ietf-calsify@osafoundation.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 17:09:05 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 779057FEF9 for ; Fri, 23 Feb 2007 07:17:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 04719142277 for ; Fri, 23 Feb 2007 07:16:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10904-05 for ; Fri, 23 Feb 2007 07:16:44 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0AF91142276 for ; Fri, 23 Feb 2007 07:16:43 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2007 16:16:43 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1NFGgJN018375; Fri, 23 Feb 2007 16:16:42 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4187.cisco.com [10.61.80.90]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1NFGfC8004819; Fri, 23 Feb 2007 16:16:41 +0100 (MET) Message-ID: <45DF0558.2040603@cisco.com> Date: Fri, 23 Feb 2007 16:16:40 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty References: <20070223124028.E853F14227B@laweleka.osafoundation.org> <03081CF105D729594224FCAD@caldav.apple.com> In-Reply-To: <03081CF105D729594224FCAD@caldav.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3970; t=1172243802; x=1173107802; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20Section=203.8.4.7=3A=20Recommended=2 0syntax=20for=09the=09UIDproperty |Sender:=20; bh=ciC9ui2XuyRduQ1Lzc016EkgL+Aw/8E+M1plrfhWFEM=; b=KHsmwQeqr7plQORRLtqnbtcirLNeJdZLIBUXHsuICOwlyKMt9Xyx6QRPQd0BcGyF2G2q4aHs X+wr6QR83JxSsqnfHWHD6Chv5hT8mDt2cAYm3uAKiaw0udTg935yLdDK; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT, TW_UU X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 15:17:40 -0000 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 > 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. > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AE56880306 for ; Fri, 23 Feb 2007 07:09:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3BF23142276 for ; Fri, 23 Feb 2007 07:08:54 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12212-09 for ; Fri, 23 Feb 2007 07:08:53 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F653142274 for ; Fri, 23 Feb 2007 07:08:52 -0800 (PST) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1NF8iCd010668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Feb 2007 10:08:47 -0500 Date: Fri, 23 Feb 2007 10:08:43 -0500 From: Cyrus Daboo To: Tim Hare , ietf-calsify@osafoundation.org Subject: RE: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty Message-ID: <03081CF105D729594224FCAD@caldav.apple.com> In-Reply-To: <20070223124028.E853F14227B@laweleka.osafoundation.org> References: <20070223124028.E853F14227B@laweleka.osafoundation.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, MISSING_SUBJECT, TW_UU X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 15:09:48 -0000 Hi Tim, --On February 23, 2007 7:38:37 AM -0500 Tim Hare 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 216A17F526 for ; Fri, 23 Feb 2007 04:41:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 91BE914227D for ; Fri, 23 Feb 2007 04:40:29 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11239-02 for ; Fri, 23 Feb 2007 04:40:28 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by laweleka.osafoundation.org (Postfix) with ESMTP id E853F14227B for ; Fri, 23 Feb 2007 04:40:28 -0800 (PST) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc12) with SMTP id <20070223124027m1200j7ngue>; Fri, 23 Feb 2007 12:40:28 +0000 From: "Tim Hare" To: Subject: RE: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UIDproperty Date: Fri, 23 Feb 2007 07:38:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <45DE8F04.6060806@webfeet.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AcdXFyUAefq8x2twRTWBXBHhn8RPCQALSbSw Message-Id: <20070223124028.E853F14227B@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=3.3 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, MISSING_SUBJECT, MSGID_FROM_MTA_ID X-Spam-Level: *** X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 12:41:24 -0000 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Martin Kiff Sent: Friday, February 23, 2007 1:52 AM To: Cyrus Daboo Cc: ietf-calsify@osafoundation.org 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 > 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E99DF7FD53 for ; Thu, 22 Feb 2007 22:52:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 77341142273 for ; Thu, 22 Feb 2007 22:52:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05673-10 for ; Thu, 22 Feb 2007 22:52:00 -0800 (PST) Received: from mail.zserv.tuwien.ac.at (mail.zserv.tuwien.ac.at [128.130.35.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id AF809142272 for ; Thu, 22 Feb 2007 22:51:58 -0800 (PST) Received: from [192.168.0.101] (v226-019.vpm.tuwien.ac.at [128.131.226.19]) by mail.zserv.tuwien.ac.at (@(#)Sendmail version 8.13.3 - Revision 1.003 - 05/24/2006/8.13.1) with ESMTP id l1N6pn9Y004881; Fri, 23 Feb 2007 07:51:49 +0100 (MEZ) Message-ID: <45DE8F04.6060806@webfeet.co.uk> Date: Fri, 23 Feb 2007 07:51:48 +0100 From: Martin Kiff User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> <64F57A39D538EB4CDBFEEE89@caldav.apple.com> In-Reply-To: <64F57A39D538EB4CDBFEEE89@caldav.apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 06:52:59 -0000 Cyrus Daboo wrote: > Hi Martin, > > --On February 22, 2007 4:39:48 PM +0100 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. > > > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 70BB97F97F for ; Thu, 22 Feb 2007 08:00:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 01AA2142254 for ; Thu, 22 Feb 2007 08:00:02 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30089-09 for ; Thu, 22 Feb 2007 08:00:00 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4B300142253 for ; Thu, 22 Feb 2007 08:00:00 -0800 (PST) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1MFxqcq005827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Feb 2007 10:59:55 -0500 Date: Thu, 22 Feb 2007 10:59:50 -0500 From: Cyrus Daboo To: Martin Kiff , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property Message-ID: <64F57A39D538EB4CDBFEEE89@caldav.apple.com> In-Reply-To: <45DDB944.6060505@webfeet.co.uk> References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 16:00:56 -0000 Hi Martin, --On February 22, 2007 4:39:48 PM +0100 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. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 98C237FA26 for ; Thu, 22 Feb 2007 07:46:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 29FA4142254 for ; Thu, 22 Feb 2007 07:45:58 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29323-10 for ; Thu, 22 Feb 2007 07:45:55 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A791142253 for ; Thu, 22 Feb 2007 07:45:55 -0800 (PST) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Feb 2007 15:45:54 +0000 Message-ID: <45DDBA8F.50704@isode.com> Date: Thu, 22 Feb 2007 15:45:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Kiff Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property References: <45DD90D1.4010509@isode.com> <45DDB944.6060505@webfeet.co.uk> In-Reply-To: <45DDB944.6060505@webfeet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 15:46:52 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7D5F47F9FB for ; Thu, 22 Feb 2007 07:40:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E62D142254 for ; Thu, 22 Feb 2007 07:40:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30261-04 for ; Thu, 22 Feb 2007 07:39:58 -0800 (PST) Received: from mail.zserv.tuwien.ac.at (mail.zserv.tuwien.ac.at [128.130.35.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 398BD142253 for ; Thu, 22 Feb 2007 07:39:57 -0800 (PST) Received: from [192.168.0.101] (v226-019.vpm.tuwien.ac.at [128.131.226.19]) by mail.zserv.tuwien.ac.at (@(#)Sendmail version 8.13.3 - Revision 1.003 - 05/24/2006/8.13.1) with ESMTP id l1MFdmXq023633 for ; Thu, 22 Feb 2007 16:39:49 +0100 (MEZ) Message-ID: <45DDB944.6060505@webfeet.co.uk> Date: Thu, 22 Feb 2007 16:39:48 +0100 From: Martin Kiff User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property References: <45DD90D1.4010509@isode.com> In-Reply-To: <45DD90D1.4010509@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 15:40:54 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 221CE7F9DB for ; Thu, 22 Feb 2007 06:57:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C99514225E for ; Thu, 22 Feb 2007 06:56:14 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28947-02 for ; Thu, 22 Feb 2007 06:56:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id DA2C0142254 for ; Thu, 22 Feb 2007 06:56:12 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Feb 2007 15:56:06 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1MEu51f013143 for ; Thu, 22 Feb 2007 15:56:05 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4426.cisco.com [10.61.81.73]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1MEu5C8013152 for ; Thu, 22 Feb 2007 15:56:05 +0100 (MET) Message-ID: <45DDAF04.9070902@cisco.com> Date: Thu, 22 Feb 2007 15:56:04 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=74; t=1172156165; x=1173020165; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20jabber=20starts=20in=205=20minutes! |Sender:=20; bh=a0vyqxDgJ3V8BeYfQMY6hs9FfcMb0HlGd2SdhbhhQMQ=; b=TDgfHOFeGvHYzXZUcjEL6DH4ECZIt4CUQ5HwilxG17U4M6Lff/j2CCKoGa+fFsXdC5CB+wiV IPcUausbq6MUq8lwOCwgqudJmkJHhuSA9PQ04/gnwOQ0V49sQFAgpw3b; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] jabber starts in 5 minutes! X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 14:57:09 -0000 Server jabber.ietf.org, room calsify (calsify@jabber.ietf.org). Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 380677F973 for ; Thu, 22 Feb 2007 05:35:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BD5E9142253 for ; Thu, 22 Feb 2007 05:35:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27389-04 for ; Thu, 22 Feb 2007 05:35:02 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1741A14225E for ; Thu, 22 Feb 2007 05:35:02 -0800 (PST) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Feb 2007 13:35:00 +0000 Message-ID: <45DD90D1.4010509@isode.com> Date: Thu, 22 Feb 2007 12:47:13 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 3.8.4.7: Recommended syntax for the UID property X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 13:35:59 -0000 [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 @, 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 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6BA487F973 for ; Thu, 22 Feb 2007 05:35:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1136142253 for ; Thu, 22 Feb 2007 05:35:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26202-09 for ; Thu, 22 Feb 2007 05:35:02 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7158E142260 for ; Thu, 22 Feb 2007 05:35:02 -0800 (PST) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Feb 2007 13:35:01 +0000 Message-ID: <45DD91DD.9090509@isode.com> Date: Thu, 22 Feb 2007 12:51:41 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Calsify WG MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Question about section 3.1: name ABNF X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 13:35:59 -0000 >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? Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9F0CA7F973 for ; Thu, 22 Feb 2007 05:35:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FADF142253 for ; Thu, 22 Feb 2007 05:35:05 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28421-04 for ; Thu, 22 Feb 2007 05:35:03 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id C78E5142264 for ; Thu, 22 Feb 2007 05:35:02 -0800 (PST) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Feb 2007 13:35:01 +0000 Message-ID: <45DD9316.4000103@isode.com> Date: Thu, 22 Feb 2007 12:56:54 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Use of URI parameters in ORGANIZER/ATTENDEE properties, DELEGATED-FROM parameter, etc. X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 13:35:59 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DEA9F7F973 for ; Thu, 22 Feb 2007 05:35:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6EF35142266 for ; Thu, 22 Feb 2007 05:35:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26921-08 for ; Thu, 22 Feb 2007 05:35:01 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 897BF142253 for ; Thu, 22 Feb 2007 05:35:01 -0800 (PST) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Feb 2007 13:34:59 +0000 Message-ID: <45DD90B8.7020504@isode.com> Date: Thu, 22 Feb 2007 12:46:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Calsify WG MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 3.2.8: Format Type ABNF X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 13:35:59 -0000 [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 /. 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 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 32F2E7FA64 for ; Wed, 21 Feb 2007 19:17:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B978714225E for ; Wed, 21 Feb 2007 19:16:25 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23348-04 for ; Wed, 21 Feb 2007 19:16:25 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by laweleka.osafoundation.org (Postfix) with ESMTP id B869714225A for ; Wed, 21 Feb 2007 19:16:24 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id k26so394027nfc for ; Wed, 21 Feb 2007 19:16:23 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fifPIqatZqimsHig3efCiG0Jm5enFn4wIeKVXBjd1d8uMUDkR7/QvUZDm4V3bA9o1Se9PB+8dq7lbQqbF1p6m1F8I1weG0MS1W9lvjSY63x4nW/QHpgx8+UkLXAlCUgjs2kxTldr5UlKPSPcGgf/mdBfRifQ7aBBApf6SBeJbDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CCUd0cxJkU4iN8NCOHEM3jB4Gttbc9R7v578XxnBViPtmn6d6qcmkGqCCT6cxuH4vRk3HXIaR0eHeWvDOqn8dvvPYL4IusjLrRW4EyJd1veBtHQYkQEwU7eH3OqJawNGqS6HY652Dt/UyeWydeS52oXPFle9bC1C/XTm1uXlE7U= Received: by 10.82.172.15 with SMTP id u15mr28328bue.1172114183794; Wed, 21 Feb 2007 19:16:23 -0800 (PST) Received: by 10.82.157.8 with HTTP; Wed, 21 Feb 2007 19:16:23 -0800 (PST) Message-ID: <178b8d440702211916s29817793s949ed8ce6ad3b832@mail.gmail.com> Date: Wed, 21 Feb 2007 19:16:23 -0800 From: "Mike Samuel" To: "Nigel Swinson" Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <178b8d440702211910l1b7d0747sd85c86bbaa480cb1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <178b8d440702211910l1b7d0747sd85c86bbaa480cb1@mail.gmail.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 03:17:20 -0000 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 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 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 > > _______________________________________________ > > Ietf-calsify mailing list > > Ietf-calsify@osafoundation.org > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8CE947FA50 for ; Wed, 21 Feb 2007 19:11:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0681214225E for ; Wed, 21 Feb 2007 19:10:38 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20220-07 for ; Wed, 21 Feb 2007 19:10:37 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0AF5314225A for ; Wed, 21 Feb 2007 19:10:36 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id k26so392909nfc for ; Wed, 21 Feb 2007 19:10:36 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ckGmuvJbjEhf7HPo8g3ZU5ACsqgZYfyxodMm/Sj6/nlfGlcZMGtrAv3l9r4zEHDYXXuyXdXiQHnh1u+cX11KWBFT3dRzcTUihfglIKpMto6rwESTS4i8Z0u79LN0a2vnK6cJF+VT+4LCY2ExssO9ytL8vWa6ShOs6+psGaGanbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VmOGE8H5+lZPewhiI+hlBp+XtHOxdlllEPzpuSqSfTIqubwvvkI1BKs3yLMQ2mbUwtC5GfDNQpllNdPUVBWGpzfcrFHfLALOKkTSfeyd84hTl2vaSkCb67+EuRDDbAOt1RSUV6G0xa587Tb2NrzGaFs8EMg18y9BwSOHq6MXRbM= Received: by 10.82.118.2 with SMTP id q2mr29251buc.1172113835896; Wed, 21 Feb 2007 19:10:35 -0800 (PST) Received: by 10.82.157.8 with HTTP; Wed, 21 Feb 2007 19:10:35 -0800 (PST) Message-ID: <178b8d440702211910l1b7d0747sd85c86bbaa480cb1@mail.gmail.com> Date: Wed, 21 Feb 2007 19:10:35 -0800 From: "Mike Samuel" To: "Nigel Swinson" Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <014c01c75482$31efa8a0$0202fea9@nigelhome> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <014c01c75482$31efa8a0$0202fea9@nigelhome> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 03:11:33 -0000 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 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 467EE7F4D2 for ; Wed, 21 Feb 2007 12:56:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CDEAC14225A for ; Wed, 21 Feb 2007 12:55:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18202-10 for ; Wed, 21 Feb 2007 12:55:46 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by laweleka.osafoundation.org (Postfix) with ESMTP id CAC17142256 for ; Wed, 21 Feb 2007 12:55:45 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id 30so1010127ugs for ; Wed, 21 Feb 2007 12:55:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EG00SYmznzM+kCmGsuZFjLMRSKGwg1Kc0wUe8NrIs7zfcqE4eaps2tUBgJCbFQEorKNQNWIof2z5C6B4nQ/LRA6sdWvKXoMI4avIH+zsnYdZaDHch5uufImZBRuKDgZ1jX/6VNwxu4NVd0q0LmgfmcyyLps92YHyRVmTK9ePJkA= Received: by 10.82.138.6 with SMTP id l6mr3116175bud.1172091343371; Wed, 21 Feb 2007 12:55:43 -0800 (PST) Received: by 10.82.157.8 with HTTP; Wed, 21 Feb 2007 12:55:43 -0800 (PST) Message-ID: <178b8d440702211255y692fede8v3db5965a2f58763e@mail.gmail.com> Date: Wed, 21 Feb 2007 12:55:43 -0800 From: "Mike Samuel" To: "Nigel Swinson" Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. In-Reply-To: <003401c755da$a43c3870$0202fea9@nigelhome> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <200702200738.08127.reinhold@kainhofer.com> <003401c755da$a43c3870$0202fea9@nigelhome> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 20:56:42 -0000 On 21/02/07, Nigel Swinson 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 > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6366F7FA69 for ; Wed, 21 Feb 2007 09:07:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E759014225D for ; Wed, 21 Feb 2007 09:06:20 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15298-03 for ; Wed, 21 Feb 2007 09:06:20 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3879414225B for ; Wed, 21 Feb 2007 09:06:20 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 01b45ac7be28df977b46494d3029e009 X-Spam-Score-Summary: 2, 0, 0, d4972121ed74af80, 5c6910fe347e04a0, nigel.swinson@rockliffe.com, , 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 X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-15 Received: from nigelhome (unverified [10.42.40.208]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Wed, 21 Feb 2007 09:06:19 -0800 Message-ID: <003401c755da$a43c3870$0202fea9@nigelhome> From: "Nigel Swinson" To: References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <200702200738.08127.reinhold@kainhofer.com> Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. Date: Wed, 21 Feb 2007 17:06:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 17:07:15 -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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4A87A7FCCC for ; Wed, 21 Feb 2007 07:51:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CECA814225B for ; Wed, 21 Feb 2007 07:50:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14680-07 for ; Wed, 21 Feb 2007 07:50:08 -0800 (PST) Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 337D814225A for ; Wed, 21 Feb 2007 07:50:08 -0800 (PST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 78ECD1761E; Wed, 21 Feb 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJtjG-0008TG-83; Wed, 21 Feb 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Feb 2007 10:50:02 -0500 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Spam-Level: Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-03.txt X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 15:51:03 -0000 --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 . The issue tracker for the Calsify WG is located at: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-21085130.I-D@ietf.org> 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: <2007-2-21085130.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0EEFA7F9EA for ; Mon, 19 Feb 2007 22:39:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9896914226F for ; Mon, 19 Feb 2007 22:38:15 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23198-04 for ; Mon, 19 Feb 2007 22:38:14 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9742414225A for ; Mon, 19 Feb 2007 22:38:13 -0800 (PST) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1K6cAAr024848 for ; Tue, 20 Feb 2007 07:38:10 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. Date: Tue, 20 Feb 2007 07:38:03 +0100 User-Agent: KMail/1.9.5 + Features References: <014c01c75482$31efa8a0$0202fea9@nigelhome> In-Reply-To: <014c01c75482$31efa8a0$0202fea9@nigelhome> Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702200738.08127.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 06:39:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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) iD8DBQFF2pdQTqjEwhXvPN0RAuvxAJ0c/Z9B0McoiHq/p+Por95VZK7ibACcDXLC NY6IyvMHIhHcHyItDWJ3wcM= =VaNN -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A90E17F7DE for ; Mon, 19 Feb 2007 20:44:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3EE9314226F for ; Mon, 19 Feb 2007 20:43:12 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23542-03 for ; Mon, 19 Feb 2007 20:43:10 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8F4D614226E for ; Mon, 19 Feb 2007 20:43:10 -0800 (PST) Received: from [10.0.1.5] ([10.0.1.5]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1K4h1H4019110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Feb 2007 23:43:06 -0500 Date: Mon, 19 Feb 2007 23:43:01 -0500 From: Cyrus Daboo To: George Sexton , ietf-calsify Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. Message-ID: <20ABEE9E3E9C98F6500E0900@ninevah.local> In-Reply-To: <45DA76D5.1000307@mhsoftware.com> References: <014c01c75482$31efa8a0$0202fea9@nigelhome> <45DA76D5.1000307@mhsoftware.com> X-Mailer: Mulberry/4.0.7 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 04:44:06 -0000 Hi George, --On February 19, 2007 9:19:33 PM -0700 George Sexton 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 428FE7F9BB for ; Mon, 19 Feb 2007 20:20:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CBBEB14226F for ; Mon, 19 Feb 2007 20:19:39 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19437-09 for ; Mon, 19 Feb 2007 20:19:38 -0800 (PST) Received: from mail.mhsoftware.com (mail.mhsoftware.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 121E014226E for ; Mon, 19 Feb 2007 20:19:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 3F8E329ABB8D for ; Mon, 19 Feb 2007 21:19:37 -0700 (MST) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00899-03 for ; Mon, 19 Feb 2007 21:19:36 -0700 (MST) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 9212429A7C0C for ; Mon, 19 Feb 2007 21:19:36 -0700 (MST) Message-ID: <45DA76D5.1000307@mhsoftware.com> Date: Mon, 19 Feb 2007 21:19:33 -0700 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ietf-calsify Subject: Re: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. References: <014c01c75482$31efa8a0$0202fea9@nigelhome> In-Reply-To: <014c01c75482$31efa8a0$0202fea9@nigelhome> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 04:20:34 -0000 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 > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E71657F67E for ; Mon, 19 Feb 2007 16:01:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F89114226D for ; Mon, 19 Feb 2007 16:00:14 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21511-04 for ; Mon, 19 Feb 2007 16:00:10 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id ADDBF142257 for ; Mon, 19 Feb 2007 16:00:10 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 25d569e413820ea199895ee0491dc9e3 X-Spam-Score-Summary: 2, 0, 0, a53aceec76df4c0a, 0ccc676e4aeb5ad6, nigel.swinson@rockliffe.com, , 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 X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1,iso-8859-1,windows-1252,windows-1252 Received: from nigelhome (unverified [10.42.40.210]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Mon, 19 Feb 2007 16:00:06 -0800 Message-ID: <014c01c75482$31efa8a0$0202fea9@nigelhome> From: "Nigel Swinson" To: Date: Tue, 20 Feb 2007 00:00:54 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0149_01C75482.30C33690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-calsify] FREQ=MONTHLY when DTSTART = 29/30/31st. X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 00:01:09 -0000 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
Please could you confirm to me that the following does not include = the 15th=20 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
 
DTSTART;VALUE=3DDATE:20070130
RRULE:FREQ=3DDAILY;BYMONTHDAY=3D15,30
 
 
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.  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.
 
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.  I suggest we move the "invalid date" paragraph down = one, and=20 then:
 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05#se= ction-3.3.10
 
      Information, not contained in the = rule,=20 necessary to determine the
      various = recurrence=20 instance start time and dates are derived = from
     =20 the Start Time ("DTSTART") component attribute.  For=20 example,
      "FREQ=3DYEARLY;BYMONTH=3D1" = doesn't=20 specify a specific day within the
      = month or a=20 time.  This information would be the same as what=20 is
      specified for "DTSTART".
 
      Recurrence rules may generate = recurrence=20 instances with invalid
      date (e.g., = February=20 30) or nonexistent local time (e.g., 1:30 = AM
     =20 on a day where the local time is moved forward by an hour at=20 1:00
      AM).  Such recurrence = instances MUST=20 be ignored and MUST NOT be
      counted as = part of=20 the recurrence set.
+    Should the combination of = DTSTART and=20 FREQ itself create
+    recurrences that lie on non existant dates, = then you=20 end up skipping
+    entire intervals.  For example=20 "DTSTART;VALUE=3DDATE:20070130" with
+    "FREQ=3DMONTHLY" will never contain any = instances in=20 February regardless
+    of what BYXXX rule parts are specified.
 
      If multiple BYxxx rule parts are = specified,=20 then after evaluating
      the specified = FREQ and=20 INTERVAL rule parts, the BYxxx rule = parts
      are=20 applied to the current set of evaluated occurrences in=20 the
      following order: BYMONTH, = BYWEEKNO,=20 BYYEARDAY, BYMONTHDAY, BYDAY,
      BYHOUR,=20 BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL=20 are
      evaluated.
Cheers
 
Nigel
------=_NextPart_000_0149_01C75482.30C33690-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F2F807F62F for ; Mon, 19 Feb 2007 13:34:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8BD8D14226E for ; Mon, 19 Feb 2007 13:34:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20395-03 for ; Mon, 19 Feb 2007 13:33:59 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C4D6514226B for ; Mon, 19 Feb 2007 13:33:58 -0800 (PST) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1JLXXHW017951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Feb 2007 16:33:36 -0500 Date: Mon, 19 Feb 2007 16:33:28 -0500 From: Cyrus Daboo To: Bernard Desruisseaux , ietf-calsify@osafoundation.org Subject: Re: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] Message-ID: In-Reply-To: <45D9D2BB.3000803@oracle.com> References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> <45C7741C.8090608@oracle.com> <45D9D2BB.3000803@oracle.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.9 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 21:34:55 -0000 Hi Bernard, --On February 19, 2007 11:39:23 AM -0500 Bernard Desruisseaux 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5D7087F62F for ; Mon, 19 Feb 2007 13:31:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E943B14226D for ; Mon, 19 Feb 2007 13:30:54 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20292-04 for ; Mon, 19 Feb 2007 13:30:54 -0800 (PST) Received: from mail.zserv.tuwien.ac.at (mail.zserv.tuwien.ac.at [128.130.35.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2416314226B for ; Mon, 19 Feb 2007 13:30:53 -0800 (PST) Received: from [192.168.0.101] (v226-019.vpm.tuwien.ac.at [128.131.226.19]) by mail.zserv.tuwien.ac.at (@(#)Sendmail version 8.13.3 - Revision 1.003 - 05/24/2006/8.13.1) with ESMTP id l1JLUilv001977 for ; Mon, 19 Feb 2007 22:30:46 +0100 (MEZ) Message-ID: <45DA1703.1040700@webfeet.co.uk> Date: Mon, 19 Feb 2007 22:30:43 +0100 From: Martin Kiff User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> <45C7741C.8090608@oracle.com> <45D9D2BB.3000803@oracle.com> In-Reply-To: <45D9D2BB.3000803@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 21:31:49 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3F7FA7F64F for ; Mon, 19 Feb 2007 08:41:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C807014226F for ; Mon, 19 Feb 2007 08:40:48 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17090-04 for ; Mon, 19 Feb 2007 08:40:47 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EA13A14226E for ; Mon, 19 Feb 2007 08:40:46 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l1JGeiiv008844; Mon, 19 Feb 2007 09:40:44 -0700 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1JFU0Di004280; Mon, 19 Feb 2007 09:40:43 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2460908071171903165; Mon, 19 Feb 2007 09:39:25 -0700 Message-ID: <45D9D2BB.3000803@oracle.com> Date: Mon, 19 Feb 2007 11:39:23 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Handling of DUE;VALUE=DATE [Issue 10: Re: [Ietf-calsify] All Day Events and DTEND] References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> <45C7741C.8090608@oracle.com> In-Reply-To: <45C7741C.8090608@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 16:41:43 -0000 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 >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B19C77F525 for ; Fri, 16 Feb 2007 10:47:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 066CD14226B for ; Fri, 16 Feb 2007 10:46:51 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12853-05 for ; Fri, 16 Feb 2007 10:46:49 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1373F142269 for ; Fri, 16 Feb 2007 10:46:48 -0800 (PST) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1GIkcom020557; Fri, 16 Feb 2007 19:46:40 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: George Sexton 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 User-Agent: KMail/1.9.5 + Features References: <454E66AA.9060809@oracle.com> <200702161821.58133.reinhold@kainhofer.com> <45D5EB72.5040507@mhsoftware.com> In-Reply-To: <45D5EB72.5040507@mhsoftware.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702161946.37288.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 18:47:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Freitag, 16. Februar 2007 schrieb George Sexton: > Reinhold Kainhofer wrote: > > 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 > 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1fwNTqjEwhXvPN0RAjP7AJ9lz+dgm/vf+Xi2udpo28eNn70wQACgzMJG 28UgXyYh6cLYk2jXDkPLcos= =KcRT -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EEE357F97B for ; Fri, 16 Feb 2007 09:36:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9180E14226B for ; Fri, 16 Feb 2007 09:35:50 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13999-02 for ; Fri, 16 Feb 2007 09:35:49 -0800 (PST) Received: from mail.mhsoftware.com (mail.mhsoftware.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DF864142255 for ; Fri, 16 Feb 2007 09:35:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 7707B29AB115; Fri, 16 Feb 2007 10:35:48 -0700 (MST) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04082-09; Fri, 16 Feb 2007 10:35:48 -0700 (MST) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id D3AB229257AF; Fri, 16 Feb 2007 10:35:47 -0700 (MST) Message-ID: <45D5EB72.5040507@mhsoftware.com> Date: Fri, 16 Feb 2007 10:35:46 -0700 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Reinhold Kainhofer Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART References: <454E66AA.9060809@oracle.com> <16A3AF236A50F93ADD607820@caldav.apple.com> <45D5DF12.4040701@mhsoftware.com> <200702161821.58133.reinhold@kainhofer.com> In-Reply-To: <200702161821.58133.reinhold@kainhofer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 17:36:45 -0000 Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 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 > > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, Austria > email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ > * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ > * K Desktop Environment, http://www.kde.org, KOrganizer maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFF1eg2TqjEwhXvPN0RAlK1AKCGUy52PEXheAgTZ5ietz9Btes7KQCgsZh7 > VVCrHFWJKnpZDyskuA834yg= > =YOSl > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1BA057F9D0 for ; Fri, 16 Feb 2007 09:23:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B3157142255 for ; Fri, 16 Feb 2007 09:22:06 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14048-07 for ; Fri, 16 Feb 2007 09:22:04 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D0E9214226B for ; Fri, 16 Feb 2007 09:22:03 -0800 (PST) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1GHLxdf008601 for ; Fri, 16 Feb 2007 18:22:01 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org 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 User-Agent: KMail/1.9.5 + Features References: <454E66AA.9060809@oracle.com> <16A3AF236A50F93ADD607820@caldav.apple.com> <45D5DF12.4040701@mhsoftware.com> In-Reply-To: <45D5DF12.4040701@mhsoftware.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702161821.58133.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 17:23:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1eg2TqjEwhXvPN0RAlK1AKCGUy52PEXheAgTZ5ietz9Btes7KQCgsZh7 VVCrHFWJKnpZDyskuA834yg= =YOSl -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 82A467F738 for ; Fri, 16 Feb 2007 08:43:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 246B614226E for ; Fri, 16 Feb 2007 08:43:02 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13162-05 for ; Fri, 16 Feb 2007 08:43:00 -0800 (PST) Received: from mail.mhsoftware.com (mail.mhsoftware.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 541CF142269 for ; Fri, 16 Feb 2007 08:43:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id B5D5D29AB0F4 for ; Fri, 16 Feb 2007 09:42:59 -0700 (MST) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03874-09 for ; Fri, 16 Feb 2007 09:42:59 -0700 (MST) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 16F6129AA82D for ; Fri, 16 Feb 2007 09:42:58 -0700 (MST) Message-ID: <45D5DF12.4040701@mhsoftware.com> Date: Fri, 16 Feb 2007 09:42:58 -0700 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ietf-calsify Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> <45D4D3C7.8000307@oracle.com> <45D4D64A.6030709@mhsoftware.com> <16A3AF236A50F93ADD607820@caldav.apple.com> In-Reply-To: <16A3AF236A50F93ADD607820@caldav.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 16:43:57 -0000 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 > 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/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 155667F6E6 for ; Fri, 16 Feb 2007 07:13:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AD81B142267 for ; Fri, 16 Feb 2007 07:12:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12979-02 for ; Fri, 16 Feb 2007 07:12:45 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C3C3A142266 for ; Fri, 16 Feb 2007 07:12:44 -0800 (PST) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1GFCZjJ021897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Feb 2007 10:12:38 -0500 Date: Fri, 16 Feb 2007 10:12:30 -0500 From: Cyrus Daboo To: George Sexton , ietf-calsify@osafoundation.org Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART Message-ID: <16A3AF236A50F93ADD607820@caldav.apple.com> In-Reply-To: <45D4D64A.6030709@mhsoftware.com> References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> <45D4D3C7.8000307@oracle.com> <45D4D64A.6030709@mhsoftware.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.9 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 15:13:40 -0000 Hi George, --On February 15, 2007 2:53:14 PM -0700 George Sexton 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 23CAF7F9D0 for ; Thu, 15 Feb 2007 17:42:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BBCBE142255 for ; Thu, 15 Feb 2007 17:42:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05298-06 for ; Thu, 15 Feb 2007 17:41:59 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DFB43142254 for ; Thu, 15 Feb 2007 17:41:58 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l1G1fhE1019767; Thu, 15 Feb 2007 18:41:44 -0700 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1G1fhAk011990; Thu, 15 Feb 2007 18:41:43 -0700 Received: from dhcp-amer-whq-csvpn-gw3-141-144-80-118.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 2453559411171590063; Thu, 15 Feb 2007 18:41:03 -0700 Message-ID: <45D50BB1.3040005@oracle.com> Date: Thu, 15 Feb 2007 20:41:05 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Reinhold Kainhofer Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? References: <45D4CC35.1040508@oracle.com> <200702152335.40461.reinhold@kainhofer.com> In-Reply-To: <200702152335.40461.reinhold@kainhofer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 01:42:57 -0000 Hi Reinhold, Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, Austria > email: reinhold@kainhofer.com, 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) > > iD8DBQFF1OA8TqjEwhXvPN0RAmfvAKCLY1n1ho8M1DlZ42iAGI1Nuf9AnwCgp0J5 > cenbhO/IL3ap3qTgT1VhfjQ= > =PVE8 > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 470A97F9F9 for ; Thu, 15 Feb 2007 14:36:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE8BD142255 for ; Thu, 15 Feb 2007 14:35:43 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02477-04 for ; Thu, 15 Feb 2007 14:35:42 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DA433142254 for ; Thu, 15 Feb 2007 14:35:41 -0800 (PST) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1FMZcnR021080 for ; Thu, 15 Feb 2007 23:35:38 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org 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 User-Agent: KMail/1.9.5 + Features References: <45D4CC35.1040508@oracle.com> In-Reply-To: <45D4CC35.1040508@oracle.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702152335.40461.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 22:36:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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) iD8DBQFF1OA8TqjEwhXvPN0RAmfvAKCLY1n1ho8M1DlZ42iAGI1Nuf9AnwCgp0J5 cenbhO/IL3ap3qTgT1VhfjQ= =PVE8 -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 221B07F9F9 for ; Thu, 15 Feb 2007 13:54:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A1C00142254 for ; Thu, 15 Feb 2007 13:53:18 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00335-04 for ; Thu, 15 Feb 2007 13:53:16 -0800 (PST) Received: from mail.mhsoftware.com (mail.mhsoftware.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A3A8C142250 for ; Thu, 15 Feb 2007 13:53:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 3893E29AAAC6 for ; Thu, 15 Feb 2007 14:53:16 -0700 (MST) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12745-03 for ; Thu, 15 Feb 2007 14:53:15 -0700 (MST) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 8920E29AA8F2 for ; Thu, 15 Feb 2007 14:53:15 -0700 (MST) Message-ID: <45D4D64A.6030709@mhsoftware.com> Date: Thu, 15 Feb 2007 14:53:14 -0700 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> <45D4D3C7.8000307@oracle.com> In-Reply-To: <45D4D3C7.8000307@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 21:54:14 -0000 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 >>>>> >>>>> Reinhold Kainhofer wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>>>>> > The "DTSTART" property defines the first instance in the >>>>>>> > recurrence set. >>>>>>> >>>>>>> I believe this section should clarify that the "RDATE" property >>>>>>> value can actually be earlier in time than the value of the >>>>>>> "DTSTART" property. >>>>>> >>>>>> I always understood this sentence that the DTSTART is always the >>>>>> first date/time of the event and RDATE cannot be earlier. >>>>>> Otherwise, to determine whether an event happens today, one would >>>>>> have to look at all recurrences of all events, future or past. If >>>>>> the DTSTART is always the first time, then it suffices to look at >>>>>> all events that have already started at the given date (i.e. >>>>>> DTSTART<=givenDateTime). >>>>>> >>>>>> Cheers, >>>>>> Reinhold >>>>>> - -- - >>>>>> ------------------------------------------------------------------ >>>>>> Reinhold Kainhofer, Vienna University of Technology, Austria >>>>>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>>>>> * Financial and Actuarial Mathematics, TU Wien, >>>>>> http://www.fam.tuwien.ac.at/ >>>>>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>>>>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG v1.4.3 (GNU/Linux) >>>>>> >>>>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>>>>> RUXtgVx4DX3mzyaAq+CT9j4= >>>>>> =5sgz >>>>>> -----END PGP SIGNATURE----- >>>>>> _______________________________________________ >>>>>> Ietf-calsify mailing list >>>>>> Ietf-calsify@osafoundation.org >>>>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>>> _______________________________________________ >>>>> Ietf-calsify mailing list >>>>> Ietf-calsify@osafoundation.org >>>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>>> >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>> >> > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E340C7F9CA for ; Thu, 15 Feb 2007 13:45:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8635A14225D for ; Thu, 15 Feb 2007 13:44:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02132-01 for ; Thu, 15 Feb 2007 13:44:22 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 961B014225C for ; Thu, 15 Feb 2007 13:44:22 -0800 (PST) Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l1FLiHW2031448; Thu, 15 Feb 2007 14:44:18 -0700 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1FLiE0X016395; Thu, 15 Feb 2007 14:44:14 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2452739531171575761; Thu, 15 Feb 2007 14:42:41 -0700 Message-ID: <45D4D3C7.8000307@oracle.com> Date: Thu, 15 Feb 2007 16:42:31 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: George Sexton Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> <45D4CB14.1010701@mhsoftware.com> In-Reply-To: <45D4CB14.1010701@mhsoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 21:45:19 -0000 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 >>>> >>>> Reinhold Kainhofer wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>>>> > The "DTSTART" property defines the first instance in the >>>>>> > recurrence set. >>>>>> >>>>>> I believe this section should clarify that the "RDATE" property >>>>>> value can actually be earlier in time than the value of the >>>>>> "DTSTART" property. >>>>> >>>>> I always understood this sentence that the DTSTART is always the >>>>> first date/time of the event and RDATE cannot be earlier. >>>>> Otherwise, to determine whether an event happens today, one would >>>>> have to look at all recurrences of all events, future or past. If >>>>> the DTSTART is always the first time, then it suffices to look at >>>>> all events that have already started at the given date (i.e. >>>>> DTSTART<=givenDateTime). >>>>> >>>>> Cheers, >>>>> Reinhold >>>>> - -- - >>>>> ------------------------------------------------------------------ >>>>> Reinhold Kainhofer, Vienna University of Technology, Austria >>>>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>>>> * Financial and Actuarial Mathematics, TU Wien, >>>>> http://www.fam.tuwien.ac.at/ >>>>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>>>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.3 (GNU/Linux) >>>>> >>>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>>>> RUXtgVx4DX3mzyaAq+CT9j4= >>>>> =5sgz >>>>> -----END PGP SIGNATURE----- >>>>> _______________________________________________ >>>>> Ietf-calsify mailing list >>>>> Ietf-calsify@osafoundation.org >>>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>> _______________________________________________ >>>> Ietf-calsify mailing list >>>> Ietf-calsify@osafoundation.org >>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>>> >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 42DCE7F95E for ; Thu, 15 Feb 2007 13:14:15 -0800 (PST) Received: from [192.168.103.129] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C4BBE142250 for ; Thu, 15 Feb 2007 13:13:20 -0800 (PST) Message-ID: <45D4CCEB.1090608@osafoundation.org> Date: Thu, 15 Feb 2007 13:13:15 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Ietf-calsify] Exchange and new timezones X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 21:14:15 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 17AEA7F95E for ; Thu, 15 Feb 2007 13:12:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AF545142254 for ; Thu, 15 Feb 2007 13:11:50 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01048-04 for ; Thu, 15 Feb 2007 13:11:50 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 38320142250 for ; Thu, 15 Feb 2007 13:11:50 -0800 (PST) Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1FLBmdK027029 for ; Thu, 15 Feb 2007 15:11:48 -0600 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1FF5Jig008013 for ; Thu, 15 Feb 2007 14:11:46 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2453244031171573823; Thu, 15 Feb 2007 14:10:23 -0700 Message-ID: <45D4CC35.1040508@oracle.com> Date: Thu, 15 Feb 2007 16:10:13 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 21:12:45 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 294957F95E for ; Thu, 15 Feb 2007 13:06:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C01B7142254 for ; Thu, 15 Feb 2007 13:05:28 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00649-04 for ; Thu, 15 Feb 2007 13:05:26 -0800 (PST) Received: from mail.mhsoftware.com (mail.mhsoftware.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CB7F4142250 for ; Thu, 15 Feb 2007 13:05:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 4FF4129AAA83; Thu, 15 Feb 2007 14:05:26 -0700 (MST) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11404-09; Thu, 15 Feb 2007 14:05:25 -0700 (MST) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 942DA29A8E52; Thu, 15 Feb 2007 14:05:25 -0700 (MST) Message-ID: <45D4CB14.1010701@mhsoftware.com> Date: Thu, 15 Feb 2007 14:05:24 -0700 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> <45D4C7E5.5010507@oracle.com> In-Reply-To: <45D4C7E5.5010507@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 21:06:24 -0000 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 >>> >>> Reinhold Kainhofer wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>>> > The "DTSTART" property defines the first instance in the >>>>> > recurrence set. >>>>> >>>>> I believe this section should clarify that the "RDATE" property >>>>> value can actually be earlier in time than the value of the >>>>> "DTSTART" property. >>>> >>>> I always understood this sentence that the DTSTART is always the >>>> first date/time of the event and RDATE cannot be earlier. >>>> Otherwise, to determine whether an event happens today, one would >>>> have to look at all recurrences of all events, future or past. If >>>> the DTSTART is always the first time, then it suffices to look at >>>> all events that have already started at the given date (i.e. >>>> DTSTART<=givenDateTime). >>>> >>>> Cheers, >>>> Reinhold >>>> - -- - >>>> ------------------------------------------------------------------ >>>> Reinhold Kainhofer, Vienna University of Technology, Austria >>>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>>> * Financial and Actuarial Mathematics, TU Wien, >>>> http://www.fam.tuwien.ac.at/ >>>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.3 (GNU/Linux) >>>> >>>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>>> RUXtgVx4DX3mzyaAq+CT9j4= >>>> =5sgz >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> Ietf-calsify mailing list >>>> Ietf-calsify@osafoundation.org >>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >>> > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A1EEE7F9D7 for ; Thu, 15 Feb 2007 12:56:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 44EE1142258 for ; Thu, 15 Feb 2007 12:55:39 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01189-02 for ; Thu, 15 Feb 2007 12:55:38 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CA59A142255 for ; Thu, 15 Feb 2007 12:55:38 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1FKtZgB005855 for ; Thu, 15 Feb 2007 14:55:35 -0600 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1FGaiJs023919 for ; Thu, 15 Feb 2007 13:55:34 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2452423681171572820; Thu, 15 Feb 2007 13:53:40 -0700 Message-ID: <45D4C84B.20800@oracle.com> Date: Thu, 15 Feb 2007 15:53:31 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART with TZOFFSETFROM X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 20:56:33 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 757DD7F9D7 for ; Thu, 15 Feb 2007 12:54:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E6ED7142255 for ; Thu, 15 Feb 2007 12:53:33 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00738-08 for ; Thu, 15 Feb 2007 12:53:31 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1DEAC142254 for ; Thu, 15 Feb 2007 12:53:31 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1FKrSs7002225 for ; Thu, 15 Feb 2007 14:53:28 -0600 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1FF5Q6W012185 for ; Thu, 15 Feb 2007 13:53:28 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2452696331171572718; Thu, 15 Feb 2007 13:51:58 -0700 Message-ID: <45D4C7E5.5010507@oracle.com> Date: Thu, 15 Feb 2007 15:51:49 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> <45CB4358.7070900@cisco.com> In-Reply-To: <45CB4358.7070900@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 20:54:29 -0000 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 >> >> Reinhold Kainhofer wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>>> > The "DTSTART" property defines the first instance in the >>>> > recurrence set. >>>> >>>> I believe this section should clarify that the "RDATE" property >>>> value can actually be earlier in time than the value of the >>>> "DTSTART" property. >>> >>> I always understood this sentence that the DTSTART is always the >>> first date/time of the event and RDATE cannot be earlier. Otherwise, >>> to determine whether an event happens today, one would have to look >>> at all recurrences of all events, future or past. If the DTSTART is >>> always the first time, then it suffices to look at all events that >>> have already started at the given date (i.e. DTSTART<=givenDateTime). >>> >>> Cheers, >>> Reinhold >>> - -- - >>> ------------------------------------------------------------------ >>> Reinhold Kainhofer, Vienna University of Technology, Austria >>> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >>> * Financial and Actuarial Mathematics, TU Wien, >>> http://www.fam.tuwien.ac.at/ >>> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >>> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.3 (GNU/Linux) >>> >>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >>> RUXtgVx4DX3mzyaAq+CT9j4= >>> =5sgz >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> Ietf-calsify mailing list >>> Ietf-calsify@osafoundation.org >>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1D8767F709 for ; Thu, 15 Feb 2007 06:56:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B2FDB142254 for ; Thu, 15 Feb 2007 06:55:20 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26772-09 for ; Thu, 15 Feb 2007 06:55:19 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 77FA0142250 for ; Thu, 15 Feb 2007 06:55:19 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Feb 2007 06:55:19 -0800 X-IronPort-AV: i="4.14,176,1170662400"; d="scan'208"; a="113067868:sNHT34056531" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1FEtItB006642 for ; Thu, 15 Feb 2007 06:55:19 -0800 Received: from elear-mac.cisco.com (dhcp-171-70-228-163.cisco.com [171.70.228.163]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1FEtGDk016513 for ; Thu, 15 Feb 2007 06:55:18 -0800 (PST) Message-ID: <45D47456.5040302@cisco.com> Date: Thu, 15 Feb 2007 06:55:18 -0800 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18; t=1171551319; x=1172415319; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20jabber=20starts=20in=205=20minutes! |Sender:=20; bh=rEmnYOenYDDV3sRr7CnrcF5b0Kjo6ZmLG4RBX4HAn3g=; b=pYgK4/wOrQhN+uJ39jSr7aXMGAWUInx7efjxB0LErAWKXpICNluvxNiSon5abmLA0vDraHSL 74arZT42CQGVviNZGbesA0QOoZU6LxtghHBD/fzAPuol9c6Iu/ctNqa8; Authentication-Results: sj-dkim-2; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] jabber starts in 5 minutes! X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 14:56:15 -0000 See you there! Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8CB287F5E2 for ; Tue, 13 Feb 2007 08:25:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3048614225A for ; Tue, 13 Feb 2007 08:24:12 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24716-08 for ; Tue, 13 Feb 2007 08:24:10 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E268142258 for ; Tue, 13 Feb 2007 08:24:10 -0800 (PST) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1DGNkAR007663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 11:23:48 -0500 Date: Tue, 13 Feb 2007 11:23:40 -0500 From: Cyrus Daboo To: Bernard Desruisseaux , Calsify WG Message-ID: In-Reply-To: <45D1E38F.5050104@oracle.com> References: <45D1E38F.5050104@oracle.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.7 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: Subject: [Ietf-calsify] Re: [Fwd: 2445bis: clarify allowed value types of date-time property combinations] X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2007 16:25:10 -0000 Hi Bernard, --On February 13, 2007 11:13:03 AM -0500 Bernard Desruisseaux 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 > > To: Bernard Desruisseaux > > CC: ietf-calsify@osafoundation.org > > > > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6358D7F5DD for ; Tue, 13 Feb 2007 08:15:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 07EB314225A for ; Tue, 13 Feb 2007 08:14:33 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23560-09 for ; Tue, 13 Feb 2007 08:14:32 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 58E36142258 for ; Tue, 13 Feb 2007 08:14:32 -0800 (PST) Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1DGEJg6030123; Tue, 13 Feb 2007 10:14:20 -0600 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1DFXdEu006097; Tue, 13 Feb 2007 09:14:16 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2445756271171383188; Tue, 13 Feb 2007 09:13:08 -0700 Message-ID: <45D1E38F.5050104@oracle.com> Date: Tue, 13 Feb 2007 11:13:03 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] [Fwd: 2445bis: clarify allowed value types of date-time property combinations] X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2007 16:15:30 -0000 [ 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 > To: Bernard Desruisseaux > CC: ietf-calsify@osafoundation.org > > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E849E7F66F for ; Mon, 12 Feb 2007 12:38:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E8A5142250 for ; Mon, 12 Feb 2007 12:37:25 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11023-04 for ; Mon, 12 Feb 2007 12:37:24 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E2DD14224C for ; Mon, 12 Feb 2007 12:37:23 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id k26so2094089nfc for ; Mon, 12 Feb 2007 12:37:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lw1xUf2R37idBKfzGBoKrdCoq4rGagdjR9dlu+Ho3NB1HO/EioHDqhhPSYzka8lmncza1EmeKiVjrvooTpibDRO5zEU8/rxS0RK1PfVIoW80kU8pWBQ9Psc1/Z87VbmTKFycwRE5zPFVhw25HKbLaIyffiodjGs+YaNfadatRXo= Received: by 10.82.120.14 with SMTP id s14mr11106406buc.1171312641901; Mon, 12 Feb 2007 12:37:21 -0800 (PST) Received: by 10.82.100.7 with HTTP; Mon, 12 Feb 2007 12:37:21 -0800 (PST) Message-ID: <178b8d440702121237u45b3774ft3d9b3c6fae3504d9@mail.gmail.com> Date: Mon, 12 Feb 2007 12:37:21 -0800 From: "Mike Samuel" To: "Nigel Swinson" Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <016901c74ed7$45ae6260$972c2a0a@nigelhome> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> <016901c74ed7$45ae6260$972c2a0a@nigelhome> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2007 20:38:20 -0000 On 12/02/07, Nigel Swinson 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 > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 902667F57B for ; Mon, 12 Feb 2007 12:20:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3728D142250 for ; Mon, 12 Feb 2007 12:19:30 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11823-09 for ; Mon, 12 Feb 2007 12:19:29 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9633E142249 for ; Mon, 12 Feb 2007 12:19:28 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id k26so2089189nfc for ; Mon, 12 Feb 2007 12:19:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XYODEUeKW+QooqOa6o7aernQRb0XSMtEPqMaWDXC8G5/IvScJkBB790EGwwMsW+sKuqKRYhp92A7ZnSQo/zxfVRBIu6UbUrhfq1IF8RpM/zB+NusL/cG3RD8TuYXSlfP/r85nyO4MgrV+8Xh2MOHG3xD776ttu4ivev4xtEVC0I= Received: by 10.82.186.5 with SMTP id j5mr10800661buf.1171311567540; Mon, 12 Feb 2007 12:19:27 -0800 (PST) Received: by 10.82.100.7 with HTTP; Mon, 12 Feb 2007 12:19:27 -0800 (PST) Message-ID: <178b8d440702121219wdc7d86aw3a2c4a5a144b1198@mail.gmail.com> Date: Mon, 12 Feb 2007 12:19:27 -0800 From: "Mike Samuel" To: "Cyrus Daboo" Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <5AD5D946DD0293CBCE3E719C@caldav.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> <5AD5D946DD0293CBCE3E719C@caldav.apple.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2007 20:20:24 -0000 On 12/02/07, Cyrus Daboo wrote: > Hi Mike, > > --On February 12, 2007 9:55:46 AM -0800 Mike Samuel > 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 > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7612F7F57B for ; Mon, 12 Feb 2007 10:58:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D24F142250 for ; Mon, 12 Feb 2007 10:57:40 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11472-02 for ; Mon, 12 Feb 2007 10:57:38 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 44C5A14224C for ; Mon, 12 Feb 2007 10:57:38 -0800 (PST) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1CIvNAZ003368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Feb 2007 13:57:26 -0500 Date: Mon, 12 Feb 2007 13:57:18 -0500 From: Cyrus Daboo To: mikesamuel@gmail.com, Nigel Swinson Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY Message-ID: <5AD5D946DD0293CBCE3E719C@caldav.apple.com> In-Reply-To: <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.6 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2007 18:58:34 -0000 Hi Mike, --On February 12, 2007 9:55:46 AM -0800 Mike Samuel 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8AF397F519 for ; Mon, 12 Feb 2007 10:55:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 31CF4142250 for ; Mon, 12 Feb 2007 10:54:27 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11419-02 for ; Mon, 12 Feb 2007 10:54:25 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id B314D14224C for ; Mon, 12 Feb 2007 10:54:25 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 9ee14957f7c5ca31f9f00df69a686c98 X-Spam-Score-Summary: 2, 0, 0, 20d930d800e6828a, 2ba588f2bbd3461c, nigel.swinson@rockliffe.com, , 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 X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 12 Feb 2007 10:54:25 -0800 Message-ID: <016901c74ed7$45ae6260$972c2a0a@nigelhome> From: "Nigel Swinson" To: References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY Date: Mon, 12 Feb 2007 18:54:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2007 18:55:21 -0000 > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E1CC57F5E3 for ; Mon, 12 Feb 2007 09:56:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 872E6142254 for ; Mon, 12 Feb 2007 09:55:52 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09951-05 for ; Mon, 12 Feb 2007 09:55:51 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7D96142253 for ; Mon, 12 Feb 2007 09:55:50 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id k26so2044956nfc for ; Mon, 12 Feb 2007 09:55:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fBrugSsDM0JldoWGoALZCASEwuPK0cKtiO+G1RLX4gNBmL1LvgdELLcDY6G4Tzb2V2tD+zGXQAxKYFphwQspdSmjrXZMD0GbdgiKGe7R5YMZBJhmkg0F0pTgCCqKgxTZ+mWWh/BU2SiJTuGMdGObkizcczzqxEnzQJXKJvzROt8= Received: by 10.82.172.15 with SMTP id u15mr11810496bue.1171302946428; Mon, 12 Feb 2007 09:55:46 -0800 (PST) Received: by 10.82.100.7 with HTTP; Mon, 12 Feb 2007 09:55:46 -0800 (PST) Message-ID: <178b8d440702120955t7ef57952kb27ee4e321ce9ec3@mail.gmail.com> Date: Mon, 12 Feb 2007 09:55:46 -0800 From: "Mike Samuel" To: "Nigel Swinson" Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2007 17:56:47 -0000 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 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 > > > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 696A38052A for ; Fri, 9 Feb 2007 18:08:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 22346142250 for ; Fri, 9 Feb 2007 18:07:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05873-08 for ; Fri, 9 Feb 2007 18:07:51 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by laweleka.osafoundation.org (Postfix) with ESMTP id 604CD142247 for ; Fri, 9 Feb 2007 18:07:51 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id 32so875133ugm for ; Fri, 09 Feb 2007 18:07:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=punGOEx1iN9nAmzkLDhHVBBO6UT/rya6hPk63LwuSoCZzB61ST7DDiyoeIkViNVhbuoGZQniU6R6Ryt3Vh6UHH28Suh7mI643nlq/+DGUp6FFYnQn0L6kdKBGxmd2M4UYb0AdhC7WEZj0tCfVt53Cmmc7E7wRL2BiKJ/QTjb4P4= Received: by 10.78.179.12 with SMTP id b12mr327330huf.1171073264826; Fri, 09 Feb 2007 18:07:44 -0800 (PST) Received: by 10.78.51.6 with HTTP; Fri, 9 Feb 2007 18:07:44 -0800 (PST) Message-ID: <91390c30702091807o651bc51aqc9b102f2d40639c7@mail.gmail.com> Date: Sat, 10 Feb 2007 13:07:44 +1100 From: "Ben Fortuna" To: "Cyrus Daboo" Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <29E3DC1CC78FEB4FBF4C3266@ninevah.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> <29E3DC1CC78FEB4FBF4C3266@ninevah.local> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2007 02:08:47 -0000 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 wrote: > Hi Ben, > > --On February 10, 2007 12:02:26 PM +1100 Ben Fortuna > 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: > > > > 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:benfortuna@gmail.com http://blogs.modularity.net.au/thenextbigthing Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 408737FE00 for ; Fri, 9 Feb 2007 17:21:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id ECCCD14225E for ; Fri, 9 Feb 2007 17:20:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07566-06 for ; Fri, 9 Feb 2007 17:20:09 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7BF4C142254 for ; Fri, 9 Feb 2007 17:20:09 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: eb906347630b1dab46d4bfc6dbf5013b X-Spam-Score-Summary: 2, 0, 0, 504fa3ba785ba7d3, 2ba588f2bbd3461c, nigel.swinson@rockliffe.com, , 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 X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 9 Feb 2007 17:20:08 -0800 Message-ID: <008201c74cb1$a6cc55c0$972c2a0a@nigelhome> From: "Nigel Swinson" To: "Ben Fortuna" , References: <004e01c74c80$a969b330$972c2a0a@nigelhome><178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY Date: Sat, 10 Feb 2007 01:20:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2007 01:21:06 -0000 > > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F2CD18058F for ; Fri, 9 Feb 2007 17:18:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 80DE9142254 for ; Fri, 9 Feb 2007 17:17:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07557-02 for ; Fri, 9 Feb 2007 17:17:09 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BD27114225A for ; Fri, 9 Feb 2007 17:17:08 -0800 (PST) Received: from [10.0.1.5] ([10.0.1.5]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l1A1H0Iv015697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Feb 2007 20:17:05 -0500 Date: Fri, 09 Feb 2007 20:16:59 -0500 From: Cyrus Daboo To: Ben Fortuna , mikesamuel@gmail.com Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY Message-ID: <29E3DC1CC78FEB4FBF4C3266@ninevah.local> In-Reply-To: <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2007 01:18:05 -0000 Hi Ben, --On February 10, 2007 12:02:26 PM +1100 Ben Fortuna 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: 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 41DBB80595 for ; Fri, 9 Feb 2007 17:16:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id ED817142254 for ; Fri, 9 Feb 2007 17:15:27 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05207-10 for ; Fri, 9 Feb 2007 17:15:26 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9CDFF14225A for ; Fri, 9 Feb 2007 17:15:26 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 9c75a27d59d5fec39b59b60dda2bd581 X-Spam-Score-Summary: 2, 0, 0, 78dd21a3dd73d89b, 2ba588f2bbd3461c, nigel.swinson@rockliffe.com, , 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 X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 9 Feb 2007 17:15:25 -0800 Message-ID: <007c01c74cb0$fd2d2da0$972c2a0a@nigelhome> From: "Nigel Swinson" To: References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY Date: Sat, 10 Feb 2007 01:15:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2007 01:16:23 -0000 > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CC213804FD for ; Fri, 9 Feb 2007 17:03:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 805BA14225D for ; Fri, 9 Feb 2007 17:02:42 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05335-09 for ; Fri, 9 Feb 2007 17:02:38 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9E51A14225B for ; Fri, 9 Feb 2007 17:02:38 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id 32so868330ugm for ; Fri, 09 Feb 2007 17:02:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DzW+dbu9GdohjWKhhFm1D/UqIhhmiV0N+56zVBgNzgFSVflxYnvAdmVHkdWI9Xx4/5DbnRaOjB+7cAFdC9F8cQMDB3pDzqesx5HN969F3pssgivadF5w67TMFokO/ZqKutnb5JxjlUgbqy56cBF6bajdC0GnlfZ8hSHUlievZjE= Received: by 10.78.176.20 with SMTP id y20mr7013hue.1171069346498; Fri, 09 Feb 2007 17:02:26 -0800 (PST) Received: by 10.78.51.6 with HTTP; Fri, 9 Feb 2007 17:02:26 -0800 (PST) Message-ID: <91390c30702091702l191e72d3jabb7b49be31b7317@mail.gmail.com> Date: Sat, 10 Feb 2007 12:02:26 +1100 From: "Ben Fortuna" To: mikesamuel@gmail.com Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c74c80$a969b330$972c2a0a@nigelhome> <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2007 01:03:37 -0000 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 wrote: > On 09/02/07, Nigel Swinson 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- xmpp:benfortuna@gmail.com http://blogs.modularity.net.au/thenextbigthing Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2DF677FED8 for ; Fri, 9 Feb 2007 12:24:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DC15A14225D for ; Fri, 9 Feb 2007 12:23:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03414-01 for ; Fri, 9 Feb 2007 12:23:24 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1590914225E for ; Fri, 9 Feb 2007 12:23:23 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id k26so1245976nfc for ; Fri, 09 Feb 2007 12:23:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JAhoqyXc3Ellf7fiPdCssbyDBOoCooM8rupOtRgjjN2uMclneIM/JRv1S21ll1/PpoSuE4YATR+jeDzEKMOjVQFUuqfuPZX60vJZ+khfZODmmkeLO2VWw7uMZeG2d+kKNYOrmRgM5e787rG8uDzMatzUt+yYoeWY9AA/immr4mI= Received: by 10.82.118.2 with SMTP id q2mr1944143buc.1171052602634; Fri, 09 Feb 2007 12:23:22 -0800 (PST) Received: by 10.82.100.7 with HTTP; Fri, 9 Feb 2007 12:23:22 -0800 (PST) Message-ID: <178b8d440702091223j27d24208t8a1e2badcc0a13cd@mail.gmail.com> Date: Fri, 9 Feb 2007 12:23:22 -0800 From: "Mike Samuel" To: "Nigel Swinson" Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <004e01c74c80$a969b330$972c2a0a@nigelhome> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c74c80$a969b330$972c2a0a@nigelhome> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 20:24:19 -0000 On 09/02/07, Nigel Swinson 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9B24780176 for ; Fri, 9 Feb 2007 12:14:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54B9014225E for ; Fri, 9 Feb 2007 12:13:31 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03608-02 for ; Fri, 9 Feb 2007 12:13:29 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C70B14225D for ; Fri, 9 Feb 2007 12:13:28 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id 32so815880ugm for ; Fri, 09 Feb 2007 12:13:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K06dSMeRZTuO6MvwPnVZ2f2PyvsQ8ly1+clTUNncEJXqHUDBVn0nKdLUTbZtDYKuyvtz9bll0ZQyyLlNxXhOZcAXon5ut/xLkVo13hukxoRcivmqfBEg7+4Mq0rjbY/KXJWS3a7Ms5evj+WwyAKqJj/sGF8WI9cucoTLeNtznz0= Received: by 10.82.114.3 with SMTP id m3mr4347722buc.1171052007061; Fri, 09 Feb 2007 12:13:27 -0800 (PST) Received: by 10.82.100.7 with HTTP; Fri, 9 Feb 2007 12:13:26 -0800 (PST) Message-ID: <178b8d440702091213y39502131md1efcdcf6016c92a@mail.gmail.com> Date: Fri, 9 Feb 2007 12:13:26 -0800 From: "Mike Samuel" To: "Nigel Swinson" Subject: Re: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY In-Reply-To: <004e01c74c80$a969b330$972c2a0a@nigelhome> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c74c80$a969b330$972c2a0a@nigelhome> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mikesamuel@gmail.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 20:14:25 -0000 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 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B43067FDEE for ; Fri, 9 Feb 2007 11:29:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E6FA14225E for ; Fri, 9 Feb 2007 11:28:51 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02792-03 for ; Fri, 9 Feb 2007 11:28:50 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 02671142250 for ; Fri, 9 Feb 2007 11:28:49 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 16b414f3490ba5852e4d342776ac8c76 X-Spam-Score-Summary: 2, 0, 0, 474305b49d130c63, 93dc32ce46acc1f7, nigel.swinson@rockliffe.com, , 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 X-Spam-Score-Countries: X-Spam-Score-Charsets: windows-1252 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Fri, 9 Feb 2007 11:28:49 -0800 Message-ID: <004e01c74c80$a969b330$972c2a0a@nigelhome> From: "Nigel Swinson" To: Date: Fri, 9 Feb 2007 19:29:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Restrict BYSETPOS to use only with BYDAY X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 19:29:46 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 98FAB7FE06 for ; Fri, 9 Feb 2007 07:42:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5258514225D for ; Fri, 9 Feb 2007 07:41:31 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29887-08 for ; Fri, 9 Feb 2007 07:41:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 99A0714225A for ; Fri, 9 Feb 2007 07:41:29 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2007 16:41:29 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l19FfS9O004306; Fri, 9 Feb 2007 16:41:28 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4470.cisco.com [10.61.81.117]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l19FfNC8001333; Fri, 9 Feb 2007 16:41:23 +0100 (MET) Message-ID: <45CC961F.6010901@cisco.com> Date: Fri, 09 Feb 2007 16:41:19 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE References: <20070209140313.88D1414225B@laweleka.osafoundation.org> In-Reply-To: <20070209140313.88D1414225B@laweleka.osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=714; t=1171035688; x=1171899688; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20Issue=2054=3A=20Remove=20FREQ=3DSECO NDLY,=09MINUTELY=20and=20BYSECOND/BYMINUTE |Sender:=20; bh=H5DgVCA3OhYL4yX9Sug6cY3LQ2wZEIymc/i6OBTU2oI=; b=gplicqzegjR3/6eNYFAgIPzWhz/4iNki7HhYSR5M4fEa8S4bIWRHJRmDGIHuR7HrbjSuZMyR ADGcJdNrsjE5SWwe7gpdw3naX6FLG8sCLgjV+VsRmQ8qNQ5yH6iRtQzY; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 15:42:25 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 379B17FB56 for ; Fri, 9 Feb 2007 06:04:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E0DF8142260 for ; Fri, 9 Feb 2007 06:03:14 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30986-07 for ; Fri, 9 Feb 2007 06:03:13 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by laweleka.osafoundation.org (Postfix) with ESMTP id 88D1414225B for ; Fri, 9 Feb 2007 06:03:13 -0800 (PST) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc13) with SMTP id <20070209140312m1300ss2abe>; Fri, 9 Feb 2007 14:03:12 +0000 From: "Tim Hare" To: Subject: RE: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE Date: Fri, 9 Feb 2007 09:01:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcdMANiKJkIvmIybSUWafpI1rAnBBQAThGBQ In-Reply-To: <45CBF52D.6020307@softdesign.net.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070209140313.88D1414225B@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.7 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, MSGID_FROM_MTA_ID X-Spam-Level: ** X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 14:04:09 -0000 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Andrew N Dowden Sent: Thursday, February 08, 2007 11:15 PM To: ietf-calsify@osafoundation.org 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 Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F24BD7F9BC for ; Thu, 8 Feb 2007 20:15:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AD3E314225D for ; Thu, 8 Feb 2007 20:14:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23630-10 for ; Thu, 8 Feb 2007 20:14:44 -0800 (PST) Received: from alias14.ihug.co.nz (alias14.ihug.co.nz [203.96.222.24]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5102814225B for ; Thu, 8 Feb 2007 20:14:41 -0800 (PST) Received: from ironport2.ihug.co.nz [203.109.254.20] by alias14.ihug.co.nz with esmtp (Exim 3.36 #1 (Debian)) id 1HFMxx-00036w-00; Fri, 09 Feb 2007 17:02:29 +1300 Received: from 203-173-214-134.dialup.ihug.co.nz (HELO [127.0.0.1]) ([203.173.214.134]) by ironport2.ihug.co.nz with ESMTP/TLS/AES256-SHA; 09 Feb 2007 17:43:11 +1300 X-Ironport-Seen: Yes Message-ID: <45CBF52D.6020307@softdesign.net.nz> Date: Fri, 09 Feb 2007 17:14:37 +1300 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Subject: Re: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE References: <45CB4003.6030008@cisco.com> In-Reply-To: <45CB4003.6030008@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 04:15:43 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 046697F7F1 for ; Thu, 8 Feb 2007 07:44:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9081C14225A for ; Thu, 8 Feb 2007 07:43:14 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18260-02 for ; Thu, 8 Feb 2007 07:43:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 092AF142250 for ; Thu, 8 Feb 2007 07:43:13 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 16:43:14 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l18FhDR0017164 for ; Thu, 8 Feb 2007 16:43:13 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18FhCC8016046 for ; Thu, 8 Feb 2007 16:43:12 +0100 (MET) Message-ID: <45CB450C.4070504@cisco.com> Date: Thu, 08 Feb 2007 16:43:08 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=700; t=1170949393; x=1171813393; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Issue=2067=3A=204.8.2.5 |Sender:=20; bh=Wy7VSp7jsIzrXpANx3v92xfJm+N6tPPRJC3uq9Iy/SY=; b=YmyJbYlDfnWwOC9abPbhVS/Y0vyBmtM4qPT5GYnSw4ueHdwSRVYbZV4muCgKFx1RBB/GMeoK CtJbAc8oEkgnRdIt5y3EBu8/UBBvyj6gMzY8cjZ/0i0S1GKKhOytqdWN; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 67: 4.8.2.5 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 15:44:09 -0000 > > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 14BB87F66F for ; Thu, 8 Feb 2007 07:36:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7DDD142260 for ; Thu, 8 Feb 2007 07:36:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16536-08 for ; Thu, 8 Feb 2007 07:36:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id D335814225D for ; Thu, 8 Feb 2007 07:36:02 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 16:36:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l18Fa1Rp029447; Thu, 8 Feb 2007 16:36:01 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18FZuC8014096; Thu, 8 Feb 2007 16:35:56 +0100 (MET) Message-ID: <45CB4358.7070900@cisco.com> Date: Thu, 08 Feb 2007 16:35:52 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART References: <454E66AA.9060809@oracle.com> <200611060940.37222.reinhold@kainhofer.com> <454F4005.7040201@oracle.com> In-Reply-To: <454F4005.7040201@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2618; t=1170948961; x=1171812961; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Issue=2063=20Re=3A=20[Ietf-calsify]=20Section=204.8.5.3=20Rec urrence=20Date/Times=3A=0A=20RDATE=20<=09DTSTART |Sender:=20; bh=eotm3JP6PatWKjSQWKL6/csS6tW20pewh5nmV/5fMFA=; b=Q12vQNbj5iEwsD5i5phpxUUlVk3co0DQy1oQIa+TSUwGUM6f7CYRaABWJAZlWPkDr/4YYvx7 rs9MuyxDyEQjE4tlgXpa/MHTejOPhZS2dwXdIS3F0xTeRA4wK3VBRqL0; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 15:36:59 -0000 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 > > Reinhold Kainhofer wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux: >>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says: >>> > The "DTSTART" property defines the first instance in the >>> > recurrence set. >>> >>> I believe this section should clarify that the "RDATE" property >>> value can actually be earlier in time than the value of the >>> "DTSTART" property. >> >> I always understood this sentence that the DTSTART is always the >> first date/time of the event and RDATE cannot be earlier. Otherwise, >> to determine whether an event happens today, one would have to look >> at all recurrences of all events, future or past. If the DTSTART is >> always the first time, then it suffices to look at all events that >> have already started at the given date (i.e. DTSTART<=givenDateTime). >> >> Cheers, >> Reinhold >> - -- - >> ------------------------------------------------------------------ >> Reinhold Kainhofer, Vienna University of Technology, Austria >> email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ >> * Financial and Actuarial Mathematics, TU Wien, >> http://www.fam.tuwien.ac.at/ >> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer >> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.3 (GNU/Linux) >> >> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6 >> RUXtgVx4DX3mzyaAq+CT9j4= >> =5sgz >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2D9DD7F792 for ; Thu, 8 Feb 2007 07:22:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E1CE814225D for ; Thu, 8 Feb 2007 07:21:44 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17973-07 for ; Thu, 8 Feb 2007 07:21:44 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5CBA514224C for ; Thu, 8 Feb 2007 07:21:44 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 16:21:44 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l18FLh8e010460 for ; Thu, 8 Feb 2007 16:21:43 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18FLhC8009797 for ; Thu, 8 Feb 2007 16:21:43 +0100 (MET) Message-ID: <45CB4003.6030008@cisco.com> Date: Thu, 08 Feb 2007 16:21:39 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=188; t=1170948103; x=1171812103; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Issue=2054=3A=20Remove=20FREQ=3DSECONDLY, =20MINUTELY=20and=20 BYSECOND/BYMINUTE |Sender:=20; bh=6r9eBQeTBLnxrIi/bairuETYAR5AIWh4EA/a+Gdflt4=; b=wJMkDoCsflvub8Hr1EzHAzCGEvnyRYI1aPNQVSnYaX8GHxmPAisP1OnOmH9t4FriU3CQxH2g Wa9SWfOa9jtiDha4Hy90t3rzcfD8DqrX7/0dw52hXiapvXbqOTlRizIF; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 54: Remove FREQ=SECONDLY, MINUTELY and BYSECOND/BYMINUTE X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 15:22:39 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2EEB47F685 for ; Thu, 8 Feb 2007 07:16:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E259C142262 for ; Thu, 8 Feb 2007 07:15:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17348-01 for ; Thu, 8 Feb 2007 07:15:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5592114225E for ; Thu, 8 Feb 2007 07:15:10 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 16:15:09 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l18FF90Y008216 for ; Thu, 8 Feb 2007 16:15:09 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18FF8C8007731 for ; Thu, 8 Feb 2007 16:15:09 +0100 (MET) Message-ID: <45CB3E79.10805@cisco.com> Date: Thu, 08 Feb 2007 16:15:05 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=148; t=1170947709; x=1171811709; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Issues=2021=20and=2054 |Sender:=20; bh=ANB6m/1029rUDYQXUIvbVAEVb8PqKrsu27UhChz5Hr4=; b=SBWHZeYSEXJFWyA8sthAYLFIIklv3Kmd91/fmTA607YvOp5TUK0irRbPcFOrh8D8H/dYMdPX AqMOMgLlyLiIqwkXQrBNEoK6Nr3sdNlLb582/Sp13zCd0/O1jeP4FE8s; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issues 21 and 54 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 15:16:05 -0000 As the changes are all backward compatible, the jabber session proposes that no version bump or new mime type is required. Objections? Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A37DF7F533 for ; Thu, 8 Feb 2007 06:54:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4AF7414225D for ; Thu, 8 Feb 2007 06:53:48 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16474-05 for ; Thu, 8 Feb 2007 06:53:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id BBEC714224C for ; Thu, 8 Feb 2007 06:53:46 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 15:53:47 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l18ErjR6015433 for ; Thu, 8 Feb 2007 15:53:45 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18EreC8001322 for ; Thu, 8 Feb 2007 15:53:44 +0100 (MET) Message-ID: <45CB3970.5000907@cisco.com> Date: Thu, 08 Feb 2007 15:53:36 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=60; t=1170946425; x=1171810425; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20continuing=20the=20issue=20slog=20on=20jabber=20in=205=20minu tes |Sender:=20; bh=AVXKhyA9qWpOHJzukNLr/TIjWbPOj39jw9Q+akZsltc=; b=YBDjkBBA4RH2PGsZ0l9DTboDhiVD5HYwquQQFaLLFuktf4HQATqVqySVeC9PlbGDS2wB3MyJ WNQm4AoDZrBAI+HmQ0vju4qLgC2nprxYeJuDz2BNcbZe55Oy1mxAcn4e; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] continuing the issue slog on jabber in 5 minutes X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 14:54:43 -0000 calsify@jabber.ietf.org. Please join if you can. Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AA9D97F6B1 for ; Wed, 7 Feb 2007 16:41:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4EA8214225C for ; Wed, 7 Feb 2007 16:41:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04550-10 for ; Wed, 7 Feb 2007 16:40:58 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.192.82]) by laweleka.osafoundation.org (Postfix) with ESMTP id CDD8214225A for ; Wed, 7 Feb 2007 16:40:58 -0800 (PST) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc12) with SMTP id <20070208004058m12006j8cke>; Thu, 8 Feb 2007 00:40:58 +0000 From: "Tim Hare" To: Subject: RE: [Ietf-calsify] Issue 62: RECURRENCE-ID Date: Wed, 7 Feb 2007 19:40:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcdLEosvBCWkGWLkQQiwMTsfCDx0ggABHqUw In-Reply-To: <200702080048.58468.reinhold@kainhofer.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070208004058.CDD8214225A@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.7 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, MSGID_FROM_MTA_ID X-Spam-Level: ** X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 00:41:54 -0000 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Reinhold Kainhofer Sent: Wednesday, February 07, 2007 6:49 PM To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: reinhold@kainhofer.com, 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----- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2F6CA7FA3A for ; Wed, 7 Feb 2007 15:49:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E545514225B for ; Wed, 7 Feb 2007 15:48:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03962-10 for ; Wed, 7 Feb 2007 15:48:46 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0B5BC14225A for ; Wed, 7 Feb 2007 15:48:45 -0800 (PST) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l17Nmh5i004281 for ; Thu, 8 Feb 2007 00:48:43 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID Date: Thu, 8 Feb 2007 00:48:58 +0100 User-Agent: KMail/1.9.5 References: <45BA2D2E.5040603@cisco.com> <76f0ff970702071516n2075005as4920db3369bcfc38@mail.gmail.com> In-Reply-To: <76f0ff970702071516n2075005as4920db3369bcfc38@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702080048.58468.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 23:49:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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= =iw+L -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F206A7F977 for ; Wed, 7 Feb 2007 15:17:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B3A8814225B for ; Wed, 7 Feb 2007 15:16:57 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03805-07 for ; Wed, 7 Feb 2007 15:16:57 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5058714225A for ; Wed, 7 Feb 2007 15:16:57 -0800 (PST) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id l17NGqU0015953 for ; Wed, 7 Feb 2007 15:16:52 -0800 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=oSpjVZTpiM5BnBg2Js/cEFRg5KcbBfPcEwBe6w1tZbRAzWuCci+E9owEWoOVRUOi0 /RE1Z7ziDLAlIYbCHlVmQ== Received: from nz-out-0506.google.com (nzes18.prod.google.com [10.36.170.18]) by zps38.corp.google.com with ESMTP id l17NFxFd031282 for ; Wed, 7 Feb 2007 15:16:45 -0800 Received: by nz-out-0506.google.com with SMTP id s18so358810nze for ; Wed, 07 Feb 2007 15:16:43 -0800 (PST) Received: by 10.114.193.1 with SMTP id q1mr1597431waf.1170890202575; Wed, 07 Feb 2007 15:16:42 -0800 (PST) Received: by 10.115.90.18 with HTTP; Wed, 7 Feb 2007 15:16:42 -0800 (PST) Message-ID: <76f0ff970702071516n2075005as4920db3369bcfc38@mail.gmail.com> Date: Wed, 7 Feb 2007 15:16:42 -0800 From: "Neal Gafter" To: "Eliot Lear" Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID In-Reply-To: <45BA2D2E.5040603@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9155_30184668.1170890202536" References: <45BA2D2E.5040603@cisco.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.2 tagged_above=-50.0 required=4.0 tests=AWL, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: Cc: "ietf-calsify@osafoundation.org" X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 23:17:52 -0000 ------=_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 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, Eliot Lear <lear@cisco.com> 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-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0855B7F5CC for ; Wed, 7 Feb 2007 10:41:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE69614225B for ; Wed, 7 Feb 2007 10:40:33 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31843-02 for ; Wed, 7 Feb 2007 10:40:33 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2E37314225A for ; Wed, 7 Feb 2007 10:40:33 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l17IdsmE017497; Wed, 7 Feb 2007 11:39:54 -0700 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l17D8PNE008877; Wed, 7 Feb 2007 11:39:53 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2430107971170873523; Wed, 07 Feb 2007 11:38:43 -0700 Message-ID: <45CA1CB1.5020703@oracle.com> Date: Wed, 07 Feb 2007 13:38:41 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE References: <45C9EF44.7090901@oracle.com> <200702071741.02928.reinhold@kainhofer.com> <75020DB80255FB52A72E55F3@caldav.apple.com> In-Reply-To: <75020DB80255FB52A72E55F3@caldav.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 18:41:28 -0000 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 > 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. > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AB6EF7F536 for ; Wed, 7 Feb 2007 10:04:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E75314225B for ; Wed, 7 Feb 2007 10:03:43 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28059-03 for ; Wed, 7 Feb 2007 10:03:41 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 93B6614225A for ; Wed, 7 Feb 2007 10:03:41 -0800 (PST) Received: from [17.101.32.44] ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l17I3JbK003522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Feb 2007 13:03:22 -0500 Date: Wed, 07 Feb 2007 13:03:15 -0500 From: Cyrus Daboo To: Reinhold Kainhofer , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE Message-ID: <75020DB80255FB52A72E55F3@caldav.apple.com> In-Reply-To: <200702071741.02928.reinhold@kainhofer.com> References: <45C9EF44.7090901@oracle.com> <200702071741.02928.reinhold@kainhofer.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.2 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 18:04:38 -0000 Hi Reinhold, --On February 7, 2007 5:40:57 PM +0100 Reinhold Kainhofer 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BB6027F566 for ; Wed, 7 Feb 2007 08:42:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D7F314225B for ; Wed, 7 Feb 2007 08:41:25 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24682-07 for ; Wed, 7 Feb 2007 08:41:21 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 883DF142257 for ; Wed, 7 Feb 2007 08:41:21 -0800 (PST) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l17Gf4eP003436 for ; Wed, 7 Feb 2007 17:41:06 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org 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 User-Agent: KMail/1.9.5 + Features References: <45C9EF44.7090901@oracle.com> In-Reply-To: <45C9EF44.7090901@oracle.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702071741.02928.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 16:42:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFygEeTqjEwhXvPN0RAkSKAKCkTS4OO8vDPFhMclxxBq8corQhBwCgz0sK g1MYOBtY2cGUjri2ovrCg7Y= =ig+Y -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 471FB7F6FE for ; Wed, 7 Feb 2007 07:27:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 08FE014225B for ; Wed, 7 Feb 2007 07:26:39 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25649-07 for ; Wed, 7 Feb 2007 07:26:37 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A30914225A for ; Wed, 7 Feb 2007 07:26:35 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l17FQXOf023729 for ; Wed, 7 Feb 2007 08:26:33 -0700 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l17D8PJo008877 for ; Wed, 7 Feb 2007 08:26:32 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2426018241170861936; Wed, 07 Feb 2007 08:25:36 -0700 Message-ID: <45C9EF44.7090901@oracle.com> Date: Wed, 07 Feb 2007 10:24:52 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 15:27:33 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 788C47F531 for ; Wed, 7 Feb 2007 03:41:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B7A1142258 for ; Wed, 7 Feb 2007 03:40:13 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21534-09 for ; Wed, 7 Feb 2007 03:40:12 -0800 (PST) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 96DC3142250 for ; Wed, 7 Feb 2007 03:40:11 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l17BankA015823 for ; Wed, 7 Feb 2007 13:37:02 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 13:39:35 +0200 Received: from [172.21.42.183] ([172.21.42.183]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Feb 2007 13:39:56 +0200 Message-ID: <45C9BA88.8050404@nokia.com> Date: Wed, 07 Feb 2007 13:39:52 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2007 11:39:56.0481 (UTC) FILETIME=[B0D33310:01C74AAC] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070207133702-3D7A1BB0-390C1FA3/0-0/0-1 X-Nokia-AV: Clean X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 74: deprecate PROCEDURE from ACTION property in VALARM X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 11:41:07 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D08707F9F9 for ; Mon, 5 Feb 2007 12:22:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9A61A142250 for ; Mon, 5 Feb 2007 12:21:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01053-05 for ; Mon, 5 Feb 2007 12:21:07 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B024014224D for ; Mon, 5 Feb 2007 12:21:06 -0800 (PST) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l15KL4Rt018345 for ; Mon, 5 Feb 2007 21:21:04 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org 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 User-Agent: KMail/1.9.5 References: <454E658D.9050804@oracle.com> <80EA29F7229D909D0A63A07A@ninevah.local> <45C78B42.4010409@oracle.com> In-Reply-To: <45C78B42.4010409@oracle.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702052121.14933.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 20:22:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, 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) iD8DBQFFx5G6TqjEwhXvPN0RAgTyAJwMXNdoucQRj/mGhQOCDhwJWUjy2QCfeVdZ YK4Jo0PMUaif5qvu605UnxE= =jRm/ -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CFC3A7F554 for ; Mon, 5 Feb 2007 11:58:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9AF68142250 for ; Mon, 5 Feb 2007 11:57:30 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01185-07 for ; Mon, 5 Feb 2007 11:57:29 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DB87E14224D for ; Mon, 5 Feb 2007 11:57:28 -0800 (PST) Received: from [17.101.32.44] ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l15JvIkL027112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Feb 2007 14:57:21 -0500 Date: Mon, 05 Feb 2007 14:57:13 -0500 From: Cyrus Daboo To: Bernard Desruisseaux Subject: Re: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE Message-ID: <57B79AA3AD07EA83D694BC55@caldav.apple.com> In-Reply-To: <45C78B42.4010409@oracle.com> References: <454E658D.9050804@oracle.com> <80EA29F7229D909D0A63A07A@ninevah.local> <45C78B42.4010409@oracle.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: Cc: Calsify WG X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 19:58:24 -0000 Hi Bernard, --On February 5, 2007 2:53:38 PM -0500 Bernard Desruisseaux 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F380D7F738 for ; Mon, 5 Feb 2007 11:56:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE681142250 for ; Mon, 5 Feb 2007 11:55:36 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01845-09 for ; Mon, 5 Feb 2007 11:55:35 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5FEFB14224D for ; Mon, 5 Feb 2007 11:55:34 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l15JtMbF004928; Mon, 5 Feb 2007 13:55:22 -0600 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l15GXbKh019873; Mon, 5 Feb 2007 12:55:21 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2423308041170705252; Mon, 05 Feb 2007 12:54:12 -0700 Message-ID: <45C78B42.4010409@oracle.com> Date: Mon, 05 Feb 2007 14:53:38 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Cyrus Daboo Subject: Issue 72: Re: [Ietf-calsify] Section 4.6.5 Time Zone Component: Not required when DTSTART is a DATE References: <454E658D.9050804@oracle.com> <80EA29F7229D909D0A63A07A@ninevah.local> In-Reply-To: <80EA29F7229D909D0A63A07A@ninevah.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Calsify WG X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 19:56:31 -0000 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 > 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. > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 69DB97F9CC for ; Mon, 5 Feb 2007 10:16:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 35A3C142255 for ; Mon, 5 Feb 2007 10:15:44 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31411-10 for ; Mon, 5 Feb 2007 10:15:42 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A2630142253 for ; Mon, 5 Feb 2007 10:15:42 -0800 (PST) Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l15IFcjO018260; Mon, 5 Feb 2007 11:15:38 -0700 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l15FUmW1022602; Mon, 5 Feb 2007 11:15:37 -0700 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2422020281170699326; Mon, 05 Feb 2007 11:15:26 -0700 Message-ID: <45C7741C.8090608@oracle.com> Date: Mon, 05 Feb 2007 13:14:52 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] All Day Events and DTEND References: <20070124040049.4044914221E@laweleka.osafoundation.org> <45B6E39A.1010705@softdesign.net.nz> <45B73E01.2070007@cisco.com> <45B7CF12.3010109@oracle.com> In-Reply-To: <45B7CF12.3010109@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 18:16:38 -0000 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 >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 824A67F738 for ; Mon, 5 Feb 2007 04:33:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 46E4C142253 for ; Mon, 5 Feb 2007 04:32:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29001-06 for ; Mon, 5 Feb 2007 04:32:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id B7078142250 for ; Mon, 5 Feb 2007 04:32:09 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Feb 2007 13:32:09 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l15CW8Tl013982 for ; Mon, 5 Feb 2007 13:32:08 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4812.cisco.com [10.61.82.203]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l15CW8C8020342 for ; Mon, 5 Feb 2007 13:32:08 +0100 (MET) Message-ID: <45C723C8.2090507@cisco.com> Date: Mon, 05 Feb 2007 13:32:08 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=385; t=1170678728; x=1171542728; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Issues=2068,=2069,=2070=3A=20DST=20discontinuities |Sender:=20; bh=i8678/PNchs5GA4Vj++iQxdEqCPPgsdhyHfQGGV0clw=; b=j9xfrupdkZHzKn144CMdJtLCIEsb518q2UfMncUYS/jC4N3Lz84yaB588o3VZ6BXbQZjbWA0 +IIxdFSDnvZwKpkdWGaUkhkWUSjKFHLX6vcy8C6A7vyH31wGneNKQKwh; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issues 68, 69, 70: DST discontinuities X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 12:33:04 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CF1E77F66D for ; Mon, 5 Feb 2007 04:15:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9B21B142250 for ; Mon, 5 Feb 2007 04:14:35 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28665-03 for ; Mon, 5 Feb 2007 04:14:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 156DF14224D for ; Mon, 5 Feb 2007 04:14:33 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Feb 2007 13:14:32 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l15CEWtf020293 for ; Mon, 5 Feb 2007 13:14:32 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4812.cisco.com [10.61.82.203]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l15CERC8014704 for ; Mon, 5 Feb 2007 13:14:31 +0100 (MET) Message-ID: <45C71FA3.9060906@cisco.com> Date: Mon, 05 Feb 2007 13:14:27 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=251; t=1170677672; x=1171541672; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Issue=2064=3A=20Section=204.8.8.2=20Request=20Status=3A=203=2 0tuples=20or=20pairs? |Sender:=20; bh=pfeFvO1+m4AYLHwtD/qGsohayML/GYtDvd05hAhLPFg=; b=Bdm24rUNloZbks1+Sdc6AbxTDnmD8NTSfe475IZlhNPOHj1gFC8xzL/FKKtxxCn1tC3J6LQe Lu88YUUmZj1nEenhzeQlAE1yxA/8fhIHP4W2jSJynKX/o8DfekPXSbHt; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 64: Section 4.8.8.2 Request Status: 3 tuples or pairs? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 12:15:29 -0000 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. Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D35397F625 for ; Fri, 2 Feb 2007 01:22:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B2E5814226F for ; Fri, 2 Feb 2007 01:21:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20637-06 for ; Fri, 2 Feb 2007 01:21:23 -0800 (PST) Received: from plumcanary.com (mail.plumcanary.com [216.154.222.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 46F2414225E for ; Fri, 2 Feb 2007 01:21:23 -0800 (PST) Received: from [192.168.1.105] (c-24-61-128-135.hsd1.ma.comcast.net [24.61.128.135]) by plumcanary.com (8.12.11.20060308/8.12.11) with ESMTP id l129K6ib018805 for ; Fri, 2 Feb 2007 04:21:15 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: Calsify WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-33-974753412 From: Jay Batson Date: Fri, 2 Feb 2007 04:19:57 -0500 X-Mailer: Apple Mail (2.752.2) Received-SPF: softfail (plumcanary.com: domain of transitioning batsonjay@plumcanary.com does not designate 24.61.128.135 as permitted sender) receiver=plumcanary.com; client-ip=24.61.128.135; helo=[192.168.1.105]; envelope-from=batsonjay@plumcanary.com; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf2-1.0.0; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-calsify] Issues with Security / Spoofing section X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2007 09:22:19 -0000 --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 batsonjay@plumcanary.com +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
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.=A0 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.=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.

ILLUSTRATIVE = BACKGROUND:
Assume:
-=A0a 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.=A0 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.=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.

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.

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.

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

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

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

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.

Comments?
-jb
=
batsonjay@plumcanary.com
+1-978-824-0111 (w)
+1-978-758-1599 (m)

= --Apple-Mail-33-974753412--