From bernard.desruisseaux at oracle.com Wed Jul 4 08:46:33 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Jul 4 08:48:54 2007 Subject: [Ietf-calsify] Should we bring back the RANGE parameter? Message-ID: <468BC0D9.5010807@oracle.com> Cyrus, At the last Jabber session you said you were tempted to bring back the RANGE parameter to allow an Organizer to cancel all future recurrence instances of a recurring component defined with an unbounded RRULE. While I understand that most applications don't handle arbitrary modifications to the RRULE property nicely, I believe it shouldn't be difficult to handle truncation of unbounded RRULE properly with the simple addition of a COUNT or UNTIL rule part. In my opinion, this would be much simpler than trying to address the 4 issues that were raised with the RANGE parameter in the following thread: http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001239.html and, more importantly, expect applications to support it. Cheers, Bernard From cyrus at daboo.name Wed Jul 4 12:17:04 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed Jul 4 12:18:11 2007 Subject: [Ietf-calsify] Re: Should we bring back the RANGE parameter? In-Reply-To: <468BC0D9.5010807@oracle.com> References: <468BC0D9.5010807@oracle.com> Message-ID: Hi Bernard, --On July 4, 2007 11:46:33 AM -0400 Bernard Desruisseaux wrote: > At the last Jabber session you said you were tempted to bring back the > RANGE parameter to allow an Organizer to cancel all future recurrence > instances of a recurring component defined with an unbounded RRULE. > > While I understand that most applications don't handle arbitrary > modifications to the RRULE property nicely, I believe it shouldn't > be difficult to handle truncation of unbounded RRULE properly with > the simple addition of a COUNT or UNTIL rule part. There is a semantic difference between sending a REQUEST that changes a rule vs sending a CANCEL to remove instances. Consider: an existing event with a series of overridden instances. The attendee's client will have the master event stored with the rrule, plus all the instances. Now the Organizer sends out a CANCEL that uses RANGE - in that case it is obvious that any overridden instances whose RECURRENCE-ID overlaps the RANGE are to be removed. Now consider the alternative you propose: in that case the Organizer has to send not only the modified master event with the RRULE but also ALL overridden instances that are not being cancelled. That would be very inefficient. So the important thing here is that its better to update a recurring event in iTIP by sending diffs. As soon as you try and change the rule you have to send out the entire set of valid instances. CANCEL, ADD and a REQUEST that uses RECURRENCE-ID are effectively "diffs" to the original set. In any case it is not just CANCEL that is an issue here. A more common case is an ongoing meeting where the location changes, or where an attendee is added or removed and those changes are ongoing. How do you do that without RANGE=THISANDFUTURE? I realize that there are issues with multiple RANGE's in the same event set, but how else can we support a use case like this? I believe that we can pin down the semantics of RANGE=THISANDFUTURE enough to do what we need (I don't care about THISANDPRIOR). -- Cyrus Daboo From lear at cisco.com Wed Jul 4 13:15:28 2007 From: lear at cisco.com (Eliot Lear) Date: Wed Jul 4 13:16:29 2007 Subject: [Ietf-calsify] tracker is down for now Message-ID: <468BFFE0.7010704@cisco.com> i've had database problems. i am still working to get them up. apologies for the inconvenience. From reinhold at kainhofer.com Wed Jul 4 13:19:45 2007 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Wed Jul 4 13:20:52 2007 Subject: [Ietf-calsify] Re: Should we bring back the RANGE parameter? In-Reply-To: References: <468BC0D9.5010807@oracle.com> Message-ID: <200707042219.48835.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 4. Juli 2007 schrieb Cyrus Daboo: > Hi Bernard, > > --On July 4, 2007 11:46:33 AM -0400 Bernard Desruisseaux > > wrote: > > At the last Jabber session you said you were tempted to bring back the > > RANGE parameter to allow an Organizer to cancel all future recurrence > > instances of a recurring component defined with an unbounded RRULE. Apart from the technical issues and the semantics, looking at a practical point: How many calendaring applications and server have implemented or might be using the RANGE concept now or in the future? 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) iD8DBQFGjADkTqjEwhXvPN0RAonEAJ9X9qxFkQ+GeFXObNhtXVWhG2meawCgjtLs Ubowh1UbRCUv96CYVSDsYQA= =RJpU -----END PGP SIGNATURE----- From bernard.desruisseaux at oracle.com Wed Jul 4 21:59:59 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Jul 4 22:01:45 2007 Subject: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring In-Reply-To: <46338F68.5040700@oracle.com> References: <46338F68.5040700@oracle.com> Message-ID: <468C7ACF.3030604@oracle.com> Here's the exact text change for this proposal. Old text: > Purpose: The property indicates the date/time that the instance > of the iCalendar object was created. New text: > Purpose: In the case of an iCalendar object that specifies a > "METHOD" property, this property specifies the date and time that > the instance of the iCalendar object was created. In the case of > an iCalendar object that doesn't specify a "METHOD" property, this > property specifies the date and time that the information > associated with the calendar component was last revised in the > calendar store. Old text: > This property is different than the "CREATED" and "LAST-MODIFIED" > properties. These two properties are used to specify when the > particular calendar data in the calendar store was created and last > modified. This is different than when the iCalendar object > representation of the calendar service information was created or > last modified. New text: > In the case of an iCalendar object that specifies a "METHOD" > property, this property is different than the "CREATED" and "LAST- > MODIFIED" properties. These two properties are used to specify > when the particular calendar data in the calendar store was > created and last modified. This is different than when the > iCalendar object representation of the calendar service > information was created or last modified. > > In the case of an iCalendar object that doesn't specify a "METHOD" > property, this property is equivalent to the "LAST-MODIFIED" > property. Cheers, Bernard Bernard Desruisseaux wrote: > In section 4.8.7.2 Date/Time Stamp of RFC 2445 it says: > > > Purpose: The property indicates the date/time that the instance of > > the iCalendar object was created. > > > > [...] > > > > Description: The value MUST be specified in the UTC time format. > > > > This property is also useful to protocols such as [IMIP] that have > > inherent latency issues with the delivery of content. This property > > will assist in the proper sequencing of messages containing iCalendar > > objects. > > > > This property is different than the "CREATED" and "LAST-MODIFIED" > > properties. These two properties are used to specify when the > > particular calendar data in the calendar store was created and last > > modified. This is different than when the iCalendar object > > representation of the calendar service information was created or > > last modified. > > As was discussed at the Calsify WG meeting in Prague, I believe we > need to clarify the purpose of the "DTSTAMP" property. > > I believe the current definition of the "DTSTAMP" property make > sense in the context of scheduling, but not so for calendaring > (i.e., calendar access). > > According to the current definition, a CalDAV server that doesn't > store the iCalendar representation of calendar resources should > always return iCalendar objects with the "DTSTAMP" property set to > the current time with the consequence that the ETag (see section > 3.11 Entity Tags of RFC 2616) of all the calendar resources would > change every second! Clearly, no serious CalDAV server implementation > would do such a thing. Returning iCalendar objects with the "DTSTAMP" > property set to the last modification time of the calendar resource > would seem more appropriate. > > One way to address this issue would be to make the "DTSTAMP" property > optional in all calendar components in the iCalendar specifications, > but to make it mandatory in all calendar components in the iTIP > specification. Actually, it might have been the original intent. > RFC 2445 was ambiguous on whether "DTSTAMP" is mandatory or optional. > (see issues 37, 38, 39 and 40). iTIP, on the other hand, was clear > that "DTSTAMP" is required in all calendar components. > > In my opinion, we should not go back on the consensus made earlier > by this WG to clarify that "DTSTAMP" is required in all calendar > components. Some calendaring applications may actually find it useful > to always have a "DTSTAMP" property in all calendar components. > Remember that the "LAST-MODIFIED" property is optional in all calendar > components. > > In order to address this issue in a way that preserves backward > compatibility with existing iCalendar applications, I propose to > modify the definition of the "DTSTAMP" property to specify that in > the context of calendaring (i.e., iCalendar object with no "METHOD" > property) its value may be set to the date and time that the calendar > component was last revised in the calendar store (i.e., same > definition as LAST-MODIFIED), but that in the context of scheduling > its value should be set to the date and time where the scheduling > message (i.e., iCalendar object with a METHOD property) was created. > > Cheers, > Bernard > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -- Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696 Oracle Server Technologies 600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2 Bernard Desruisseaux | Chef senior du d?veloppement logiciel | 514.905.8696 Oracle Technologies serveurs 600, boul. de Maisonneuve Ouest, bureau 1900 | Montr?al (Qu?bec) H3A 3J2 From cyrus at daboo.name Thu Jul 5 06:23:23 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Jul 5 06:24:40 2007 Subject: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring In-Reply-To: <468C7ACF.3030604@oracle.com> References: <46338F68.5040700@oracle.com> <468C7ACF.3030604@oracle.com> Message-ID: Hi Bernard, --On July 5, 2007 12:59:59 AM -0400 Bernard Desruisseaux wrote: > New text: > > > Purpose: In the case of an iCalendar object that specifies a > > "METHOD" property, this property specifies the date and time that > > the instance of the iCalendar object was created. In the case of > > an iCalendar object that doesn't specify a "METHOD" property, this > > property specifies the date and time that the information > > associated with the calendar component was last revised in the > > calendar store. Well "calendar store" is not defined anywhere. Plus if I happen to use iCalendar format as the native format in my calendar store this would not hold true - i.e. DTSTAMP would not change when the calendar data changed. I am also a little unsure of what "created" means in the METHOD case. For instance, in at least one implementation I have done I create the iTIP message for an event by copying that event. Are you saying that when that happens a new DTSTAMP must be used? If so, I think the term "generated" might be better than "created". Or we should be much more explicit. In fact perhaps iTIP should state that every new iTIP message, be it a PUBLISH, REQUEST, REPLY etc MUST have a new DTSTAMP generated for it. If we go down that route then maybe 2445 needs to say nothing about DTSTAMP + METHOD. -- Cyrus Daboo From lear at cisco.com Thu Jul 5 06:57:06 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Jul 5 06:58:12 2007 Subject: [Ietf-calsify] jabber starts shortly Message-ID: <468CF8B2.1060807@cisco.com> calsify@jabber.ietf.org From TimHare at comcast.net Thu Jul 5 07:14:49 2007 From: TimHare at comcast.net (Tim Hare) Date: Thu Jul 5 07:15:21 2007 Subject: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMPin the context of calendaring In-Reply-To: <468C7ACF.3030604@oracle.com> Message-ID: <20070705141421.80C49142210@laweleka.osafoundation.org> Sorry I can't make Jabber sessions, but here is an alternative text idea regarding DTSTAMP. Old text: > Purpose: The property indicates the date/time that the instance > of the iCalendar object was created. New text: > Purpose: This property is used to determine the correct version of an iCalendar > object to use, when presented with two different versions of the same object. For > example, two iTIP REQUESTs to change meeting time for the same meeting arrive, > or two different files with METHOD:PUBLISH are found describing the same events. > The object with the later DTSTAMP identifies the most recent copy and MUST be used. With this new text, I would leave the old text about CREATED and LAST-MODIFIED alone. Tim Hare Interested Bystander, Non-Inc. From bernard.desruisseaux at oracle.com Thu Jul 5 13:51:26 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Jul 5 13:53:51 2007 Subject: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring In-Reply-To: References: <46338F68.5040700@oracle.com> <468C7ACF.3030604@oracle.com> Message-ID: <468D59CE.1020801@oracle.com> Cyrus Daboo wrote: > Hi Bernard, > > --On July 5, 2007 12:59:59 AM -0400 Bernard Desruisseaux > wrote: > >> New text: >> >> > Purpose: In the case of an iCalendar object that specifies a >> > "METHOD" property, this property specifies the date and time that >> > the instance of the iCalendar object was created. In the case of >> > an iCalendar object that doesn't specify a "METHOD" property, this >> > property specifies the date and time that the information >> > associated with the calendar component was last revised in the >> > calendar store. > > Well "calendar store" is not defined anywhere. I'm simply using the same terminology that is used in RFC 2445 when describing the "LAST-MODIFIED" property. > Plus if I happen to use > iCalendar format as the native format in my calendar store this would > not hold true - i.e. DTSTAMP would not change when the calendar data > changed. Whoever changes the iCalendar object should change the value of the DTSTAMP property. If a calendar user agent modifies an iCalendar object in its local calendar store it should update the value of DTSTAMP. When a CalDAV client modifies an iCalendar object and uploads it to a CalDAV server it should update the value of the DTSTAMP property before uploading it to the server. Whether iCalendar is used as the native format in your calendar store does not matter. > > I am also a little unsure of what "created" means in the METHOD case. Again, I simply used the same terminology that is used in RFC 2445. > For instance, in at least one implementation I have done I create the > iTIP message for an event by copying that event. Are you saying that > when that happens a new DTSTAMP must be used? My understanding is that DTSTAMP should be set to the time when a iTIP messages is created/generated/rendered. > If so, I think the term > "generated" might be better than "created". I agree. We should update the description of LAST-MODIFIED as well. > Or we should be much more > explicit. In fact perhaps iTIP should state that every new iTIP message, > be it a PUBLISH, REQUEST, REPLY etc MUST have a new DTSTAMP generated > for it. Ok. > If we go down that route then maybe 2445 needs to say nothing > about DTSTAMP + METHOD. But then how would DTSTAMP differ from LAST-MODIFIED in RFC2445? Cheers, Bernard From cyrus at daboo.name Thu Jul 5 19:27:48 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Jul 5 19:28:50 2007 Subject: [Ietf-calsify] Updated recurrence rule table Message-ID: Hi folks, During today's jabber session we discussed in detail Nigel Swinson's comments on the recurrence rule table I posted a while back. Whilst we have not gone through all his comments, there were some obvious fixes to the table and notes that needed to be done, and those are attached to this message. You can see the full discussion at: . -- Cyrus Daboo -------------- next part -------------- RRULE Processing A particular BYxxx rule part may expand or limit the set of date/times generated by the rule. The expand or limit behaviour is governed by the FREQ value used for the rule. Example: RRULE:FREQ=MONTHLY;BYMONTH=1,3,5;BYDAY=MO,TU The FREQ=MONTHLY value would match each of the twelve months in a year. The BYMONTH=1,3,5 rule part limits the matching months to just the 1st, 3rd and 5th in a year. The BYDAY=MO,TU rule part adds each Monday and Tuesday within the matching months to the recurrence set. The table below shows the dependency of BYxxx rule part expand or limit behaviour on the FREQ value in the rule. When evaluating a rule, each BYxxx rule part MUST be evaluated in the order it appears in the table (i.e. BYMONTH evaluated before BYWEEKNO), irrespective of the expand or limit behaviour. The term "N/A" means that the corresponding BYxxx rule part MUST NOT be used with the corresponding FREQ value. BYDAY has some special behaviour depending on the FREQ value and this is described in separate notes below the table. +--------------------------------------------------------------------------+ | |SECONDLY|MINUTELY| HOURLY | DAILY | WEEKLY | MONTHLY | YEARLY | |----------+--------+--------+--------+--------+--------+---------+--------| |BYMONTH | Limit | Limit | Limit | Limit | Limit | Limit | Expand | |----------+--------+--------+--------+--------+--------+---------+--------| |BYWEEKNO | Limit | Limit | Limit | Limit | Limit | N/A | Expand | |----------+--------+--------+--------+--------+--------+---------+--------| |BYYEARDAY | Limit | Limit | Limit | N/A | N/A | N/A | Expand | |----------+--------+--------+--------+--------+--------+---------+--------| |BYMONTHDAY| Limit | Limit | Limit | Limit | N/A | Expand | Expand | |----------+--------+--------+--------+--------+--------+---------+--------| |BYDAY | Limit | Limit | Limit | Limit | Note 1 | Note 2 | Note 3 | |----------+--------+--------+--------+--------+--------+---------+--------| |BYHOUR | Limit | Limit | Limit | Expand | Expand | Expand | Expand | |----------+--------+--------+--------+--------+--------+---------+--------| |BYMINUTE | Limit | Limit | Expand | Expand | Expand | Expand | Expand | |----------+--------+--------+--------+--------+--------+---------+--------| |BYSECOND | Limit | Expand | Expand | Expand | Expand | Expand | Expand | |----------+--------+--------+--------+--------+--------+---------+--------| |BYSETPOS | Limit | Limit | Limit | Limit | Limit | Limit | Limit | +----------+--------+--------+--------+--------+--------+---------+--------+ +--------------------------------------------------------------------+ | Note 1 | Special expand for WEEKLY. | | | | | | A BYDAY rule part cannot have a numeric value in a | | | FREQ=WEEKLY rule (i.e. 'MO', 'TU' etc is allowed, but | | | '1MO', '2TU' is not allowed). | | | | +--------+-----------------------------------------------------------| | Note 2 | Limit if BYMONTHDAY is present, otherwise special expand | | | for MONTHLY. | | | | | | The numeric value in a BYDAY rule part in a FREQ=MONTHLY | | | rule corresponds to an offset within the month. | | | | +--------+-----------------------------------------------------------| | Note 3 | Limit if BYYEARDAY or BYMONTHDAY is present, | | | otherwise special expand for WEEKLY if BYWEEKNO present, | | | otherwise special expand for MONTHLY if BYMONTH present, | | | otherwise special expand for YEARLY. | | | | | | A BYDAY rule part cannot have a numeric value in a | | | FREQ=YEARLY rule (i.e. 'MO', 'TU' etc is allowed, but | | | '1MO', '2TU' is not allowed), if BYWEEKNO is specified. | | | | | | The numeric value in a BYDAY rule part in a FREQ=YEARLY | | | rule with a BYMONTH present corresponds to an offset | | | within the month. | | | | | | The numeric value in a BYDAY rule part in a FREQ=YEARLY | | | rule without BYWEEKNO or BYMONTH present corresponds to | | | an offset within the year. | | | | +--------+-----------------------------------------------------------+ From Dave.Thewlis at calconnect.org Fri Jul 6 09:50:53 2007 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Fri Jul 6 09:52:03 2007 Subject: [Ietf-calsify] Announcing CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts Message-ID: <468E72ED.8000602@calconnect.org> *The Calendaring and Scheduling Consortium announces Roundtable X and IOP Test Event *CalConnect would like to invite you to our Roundtable X and the associated CalConnect Interoperability Test Event, the week of September 17-21, 2007, in Cambridge, Massachusetts, hosted by M.I.T. Registration is now open for the Roundtable and/or the IOP test event. Logistics and registration information may be found at http://www.calconnect.org/roundtable10.shtml and at http://www.calconnect.org/iopseptember2007.shtml General schedule: The IOP test will begin at noon Monday and run through noon Wednesday. The Roundtable will begin at lunch on Wednesday and run through lunch on Friday. We plan to offer optional practicums on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on Wednesday morning prior to lunch. The IOP test event will involve both CalDAV and regular iCalendar, iMIP and iTIP interoperability testing scenarios. In addition, plans and preliminary work for a Mobile Calendar IOP Test Event, and the scenarios associated with that event, will be covered. Roundtables are largely comprised of technical committee sessions, which generally include reports on work accomplished or in progress, working sessions in a "committee of the whole" environment for all interested parties, and discussions about work to be undertaken. Time is also set aside for BOFs either scheduled in advance, or impromptu at the meeting. If you are not currently a member of the Consortium, you may attend a single Roundtable, or a single IOP test event, as an observer; see http://www.calconnect.org/observer.shtml for more information. Both members and non-members may participate in the IOP test events. If you think you might attend, it is advisable to book your hotel room early -- hotel rooms in Cambridge in September are hard to come by. For more information, please call or e-mail me as below. See you in Cambridge! Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) ? +1 707 498 2238 (mobile) http://www.calconnect.org ? Dave.Thewlis@calconnect.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070706/5a0cbd29/attachment.htm From Dave.Thewlis at calconnect.org Fri Jul 6 10:17:14 2007 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Fri Jul 6 10:18:24 2007 Subject: [Ietf-calsify] CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts Message-ID: <468E791A.4010508@calconnect.org> CalConnect invites you to a a one-day open workshop on vCard and what should be done about it on Tuesday, September 18, 2007, at M.I.T. in Cambridge, Massachusetts. This event is _open_ to vendors, customers, CalConnect members and non-members alike. There is no fee, but you _must_ register in advance and numbers are limited. Please see http://www.calconnect.org/vcardworkshop.shtml for more information and links to the registration and logistics pages, a general discussion list about the workshop, and a questionnaire to give us more guidance to make the workshop as productive as possible. From the workshop introduction page: vCard is a well established standard for representing and transferring contact information on computer systems and mobile devices. Having been in use for a while, a number of areas of the specification have been noted as problematic and in need of revision for fixes or enhancements. To that end, CalConnect (the Calendaring & Scheduling Consortium) is hosting a one day vCard-focused workshop event at M.I.T. in Cambridge, Massachusetts in September with the goal of bringing together the key players to help move forward vCard revision efforts. Note that an effort is already under way at the IETF (Internet Engineering Task Force) to develop a personal address book access protocol based on the CardDAV specification, and since that is based on vCard, a revision of the vCard specification will be taking place within the IETF. However, bringing together interested parties in a focused discussion at a workshop can help drive that effort and provide supporting input to it to ensure the specific needs of the key players is covered. The goal of the workshop is two-fold. First to determine the real interest in revising the vCard specification, and second to determine what needs to be revised and how to go about doing that. If you are not a CalConnect member, this is also an opportunity to stay on for Roundtable X as an observer, and we'd be delighted to have you; you will have to register separately for the Roundtable. Regardless of whether or not you are interested in attending the workshop, we would appreciate it very much if you would take a few minutes to fill out the questionnaire , as this will help provide the workshop participants with guidance as to the directions any progression on vCard should take. -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) ? +1 707 498 2238 (mobile) http://www.calconnect.org ? Dave.Thewlis@calconnect.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070706/6c689fb2/attachment-0001.htm From Dave.Thewlis at calconnect.org Fri Jul 6 18:33:25 2007 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Fri Jul 6 18:34:29 2007 Subject: [Ietf-calsify] My apologies for multiple CalConnect-related postings Message-ID: <468EED65.6010806@calconnect.org> I seem to have screwed up somehow and posted our announcement of the vCard workshop and possibly the next Roundtable multiple times to at least one of these lists. And to make it worse, many people are subscribed to two or more of them, and thus got an unnecessary flood of repeats. I apologize for the mistake, however it occurred, and will do my best to not do it again. I hope that the irritant didn't overcome the messages! Apologies again, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) ? +1 707 498 2238 (mobile) http://www.calconnect.org ? Dave.Thewlis@calconnect.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070706/5c6abd99/attachment.htm From lear at cisco.com Mon Jul 9 04:07:08 2007 From: lear at cisco.com (Eliot Lear) Date: Mon Jul 9 04:08:11 2007 Subject: [Ietf-calsify] tracker is back up Message-ID: <469216DC.5040401@cisco.com> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/ From Internet-Drafts at ietf.org Mon Jul 9 14:15:01 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Jul 9 14:16:01 2007 Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-07.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 : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Author(s) : B. Desruisseaux Filename : draft-ietf-calsify-rfc2445bis-07.txt Pages : 177 Date : 2007-7-9 This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to- dos, journal entries and free/busy information, independent of any particular calendar service or protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-07.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-rfc2445bis-07.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-rfc2445bis-07.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 lear at cisco.com Tue Jul 10 00:03:55 2007 From: lear at cisco.com (Eliot Lear) Date: Tue Jul 10 00:05:00 2007 Subject: [Ietf-calsify] draft agenda Message-ID: <46932F5B.9000706@cisco.com> 1. Agenda Bashing (1 minute) 2. Administrativia (Chairs - 3 minutes) 3. RFC2445bis Status (Chairs - 5 minutes) 4. RFC2446bis Discussion (Cyrus - the rest) From lear at cisco.com Tue Jul 10 00:12:27 2007 From: lear at cisco.com (Eliot Lear) Date: Tue Jul 10 00:13:34 2007 Subject: [Ietf-calsify] Working Group Last Call: draft-ietf-calsify-rfc2445bis-07.txt Message-ID: <4693315B.6000008@cisco.com> Dear all, Bernard has cranked out yet another iCalendar draft, and the chairs would like to congratulate him on putting together an excellent document, and thank him for his continued efforts. We would also like to thank many contributors to improving this draft, including Cyrus Daboo, Nigel Swinson, Jonathan Lennox, and Reinhold Kainhofer, just to name a few (and apologies to those who I didn't list here). draft-ietf-calsify-rfc2445bis-07 represents over 80 issues worth of changes, leaving open but a small handful. Previously, we have reviewed the draft issue by issue. As the draft becomes available for your review, we now ask a different question: is this draft ready for publication as a Proposed Standard? What issues do you see that are show stoppers? We ask that you consider this with the understanding that best is often the enemy of great, and that it is difficult to satisfy everyone in a "rough consensus" process. As such, we ask that you support the work that this group has done, while taking the time to ensure that the work we have done here is something we will be proud of years from now. And so we open Working Group Last Call on this document. This last call will last for a month, and end on August 10th, after which we will expect an updated draft to address concerns raised. And so please note that this specification is subject to change in the following ways, from this point forth: * Rough consensus for a change; these must be discussed on the list; * Moving of small portions of normative text between this document and rfc2446bis, as this group deems logical (these must be discussed on this list); * Changes required by shepherd review (I would expect these to be very few in number); substantial ones must be discussed on this list; * Changes required to clear IETF and IESG concerns; these should be discussed on this list; and * Insubstantial editorial corrections (nits); these can be sent directly to the editor. Advancing a document through the IETF process is often like a tooth extraction without pain killers. However, the process is designed to promote technical quality. We the chairs will do our best to smooth the process. Thank you all for your efforts to make this a great document. The Chairs Aki Niemi Eliot Lear -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070710/69dbc0ed/attachment.html From sla at ucolick.org Tue Jul 10 10:31:46 2007 From: sla at ucolick.org (Steve Allen) Date: Tue Jul 10 10:32:54 2007 Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt In-Reply-To: <4693315B.6000008@cisco.com> References: <4693315B.6000008@cisco.com> Message-ID: <20070710173146.GA9772@ucolick.org> In the context of metrology I wonder about the text in 3.8.1.6. Geographic Position It says The longitude and latitude values MAY be specified up to six decimal places, which will allow for accuracy to within one meter of geographical position. This is only true if the geodetic datum is specified. I point out the US DoD's instructional page to soldiers on this http://earth-info.nima.mil/GandG/publications/horizdatum.html At a more technical level I point out the partial list of datums in use at http://earth-info.nima.mil/GandG/publications/tm8358.1/tr83581b.html#ZZ23 where in the links to the graphics for table 2 it is immediately evident that some older geodetic datums upon which available maps are based differ by hundreds of meters from the more recent, satellite-geodesy-based datums. In much the same vein as quoting the standards documents for UTC, if the values used in this field are to be believed at a level of 1 meter, then it is at the least necessary to require that the latitude and longitude values be expressed in a standard geodetic datum created no earlier than the year 1980. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From lear at cisco.com Tue Jul 10 10:38:03 2007 From: lear at cisco.com (Eliot Lear) Date: Tue Jul 10 10:39:12 2007 Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt In-Reply-To: <20070710173146.GA9772@ucolick.org> References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> Message-ID: <4693C3FB.2060500@cisco.com> Steve, Thanks for your comment. Can you restate your point in a succinct proposed textual change? Eliot Steve Allen wrote: > In the context of metrology I wonder about the text in > 3.8.1.6. Geographic Position > > It says > The longitude and > latitude values MAY be specified up to six decimal places, which > will allow for accuracy to within one meter of geographical > position. > > This is only true if the geodetic datum is specified. > > I point out the US DoD's instructional page to soldiers on this > http://earth-info.nima.mil/GandG/publications/horizdatum.html > > At a more technical level I point out the partial list of datums in > use at > http://earth-info.nima.mil/GandG/publications/tm8358.1/tr83581b.html#ZZ23 > where in the links to the graphics for table 2 it is immediately > evident that some older geodetic datums upon which available maps are > based differ by hundreds of meters from the more recent, > satellite-geodesy-based datums. > > In much the same vein as quoting the standards documents for UTC, if > the values used in this field are to be believed at a level of 1 > meter, then it is at the least necessary to require that the latitude > and longitude values be expressed in a standard geodetic datum created > no earlier than the year 1980. > > -- > Steve Allen WGS-84 (GPS) > UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 > University of California Voice: +1 831 459 3046 Lng -122.06015 > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > From mrdemeanour at jackpot.uk.net Tue Jul 10 10:46:03 2007 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Tue Jul 10 10:43:44 2007 Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt In-Reply-To: <4693C3FB.2060500@cisco.com> References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> Message-ID: <4693C5DB.2000308@jackpot.uk.net> Eliot Lear wrote: > Steve, > > Thanks for your comment. Can you restate your point in a succinct > proposed textual change? If I read it correctly, it doesn't call for a textual change. It's simply pointing out that six decimal places/one meter may be spurious precision (one could add prose to that effect, of course). > > Eliot > > Steve Allen wrote: >> In the context of metrology I wonder about the text in 3.8.1.6. >> Geographic Position >> >> It says The longitude and latitude values MAY be specified up to >> six decimal places, which will allow for accuracy to within one >> meter of geographical position. >> >> This is only true if the geodetic datum is specified. >> >> I point out the US DoD's instructional page to soldiers on this >> http://earth-info.nima.mil/GandG/publications/horizdatum.html >> >> At a more technical level I point out the partial list of datums in >> use at >> http://earth-info.nima.mil/GandG/publications/tm8358.1/tr83581b.html#ZZ23 >> where in the links to the graphics for table 2 it is immediately >> evident that some older geodetic datums upon which available maps >> are based differ by hundreds of meters from the more recent, >> satellite-geodesy-based datums. >> >> In much the same vein as quoting the standards documents for UTC, >> if the values used in this field are to be believed at a level of 1 >> meter, then it is at the least necessary to require that the >> latitude and longitude values be expressed in a standard geodetic >> datum created no earlier than the year 1980. >> >> -- Steve Allen >> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room >> 165 Lat +36.99855 University of California Voice: +1 831 459 >> 3046 Lng -122.06015 Santa Cruz, CA 95064 >> http://www.ucolick.org/~sla/ Hgt +250 m From sla at ucolick.org Tue Jul 10 11:12:08 2007 From: sla at ucolick.org (Steve Allen) Date: Tue Jul 10 11:13:07 2007 Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt In-Reply-To: <4693C3FB.2060500@cisco.com> References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> Message-ID: <20070710181208.GA10007@ucolick.org> On Tue 2007-07-10T19:38:03 +0200, Eliot Lear hath writ: > Can you restate your point in a succinct > proposed textual change? Not for sure. As written I don't know what it means nor how I would come to agreement with other parties about what it means. If I give you my latitude and longitude based on the USGS topo maps on my wall it will be off by 100 meters from the WGS-84 coordinates in my .sig. I'm not sure how exactly GEO is intended to be used, by machines or humans, and I'm at a loss to reconcile the historical gotchas other than by adding several sentences. In the absence of further input about how this is expected to be used I suppose I would suggest something like this: The latitude and longitude MAY be expressed in any geodetic datum, but if the application demands 1 meter precision then the parties exchanging the information MUST agree on a particular datum. In the absence of agreement the coordinates SHOULD be interpreted as any one of ITRF, WGS-84, ETRF, or some other post-1980 satellite-based geodetic datum (all of which agree at the level of 1 m). Here are some refs ITRF http://itrf.ensg.ign.fr/ WGS-84 is defined for the US GPS system http://en.wikipedia.org/wiki/WGS84 ETRS is a product of EUREF http://lareg.ensg.ign.fr/EUREF/ -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From hardie at qualcomm.com Tue Jul 10 12:09:22 2007 From: hardie at qualcomm.com (Ted Hardie) Date: Tue Jul 10 12:10:26 2007 Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt In-Reply-To: <20070710181208.GA10007@ucolick.org> References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> <20070710181208.GA10007@ucolick.org> Message-ID: At 11:12 AM -0700 7/10/07, Steve Allen wrote: >On Tue 2007-07-10T19:38:03 +0200, Eliot Lear hath writ: >> Can you restate your point in a succinct >> proposed textual change? > >Not for sure. As written I don't know what it means nor how I would >come to agreement with other parties about what it means. > >If I give you my latitude and longitude based on the USGS topo >maps on my wall it will be off by 100 meters from the WGS-84 >coordinates in my .sig. Other IETF working groups have based their work on WGS-84, and I'd suggest that one way forward it to state that WGS-84 is the default datum. Parties could agree to interpret this field according to another datum, but would do so according to a private agreement outside this spec. Would that solve the problem? Ted >I'm not sure how exactly GEO is intended to be used, by machines >or humans, and I'm at a loss to reconcile the historical gotchas >other than by adding several sentences. > >In the absence of further input about how this is expected to be used >I suppose I would suggest something like this: > >The latitude and longitude MAY be expressed in any geodetic datum, but >if the application demands 1 meter precision then the parties >exchanging the information MUST agree on a particular datum. In the >absence of agreement the coordinates SHOULD be interpreted as any one >of ITRF, WGS-84, ETRF, or some other post-1980 satellite-based >geodetic datum (all of which agree at the level of 1 m). > >Here are some refs > >ITRF >http://itrf.ensg.ign.fr/ > >WGS-84 is defined for the US GPS system >http://en.wikipedia.org/wiki/WGS84 > >ETRS is a product of EUREF >http://lareg.ensg.ign.fr/EUREF/ > >-- >Steve Allen WGS-84 (GPS) >UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 >University of California Voice: +1 831 459 3046 Lng -122.06015 >Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From sla at ucolick.org Tue Jul 10 12:51:39 2007 From: sla at ucolick.org (Steve Allen) Date: Tue Jul 10 12:52:42 2007 Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt In-Reply-To: References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> <20070710181208.GA10007@ucolick.org> Message-ID: <20070710195139.GA10988@ucolick.org> On Tue 2007-07-10T12:09:22 -0700, Ted Hardie hath writ: > Other IETF working groups have based their work on WGS-84, > and I'd suggest that one way forward it to state that WGS-84 > is the default datum. WGS-84 is more US-centric than is required by an international specification, especially given the expectation of the Galileo Terrestrial Reference Frame GTRF http://www.ggsp.eu/ggsp_gtrf.html At the level of 1 m any of them will do. Below the level of 1 m WGS-84 has changed and as of today does not produce the same results as it did a decade ago. This is geodetically akin to the leap second -- the reference point changed -- except that in the case of GEO the current language makes it clear that nobody cares. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From andrew_dowden at softdesign.net.nz Wed Jul 11 03:10:57 2007 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Wed Jul 11 03:12:06 2007 Subject: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? In-Reply-To: <4693315B.6000008@cisco.com> References: <4693315B.6000008@cisco.com> Message-ID: <4694ACB1.2000805@softdesign.net.nz> 3.3.10. Recurrence Rule .. The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. Should the last line read?: .. BYWEEKNO or BYMONTHDAY rule parts .. or .. BYWEEKNO or BYYEARDAY rule parts .. Alternatively, does this make sense as is? -- _______________________________________________ SoftDesign Group Dowden Software Associates P O Box 31 132, Lower Hutt 5040, NEW ZEALAND From mikesamuel at gmail.com Wed Jul 11 04:30:27 2007 From: mikesamuel at gmail.com (Mike Samuel) Date: Wed Jul 11 04:31:27 2007 Subject: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? In-Reply-To: <4694ACB1.2000805@softdesign.net.nz> References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> Message-ID: <178b8d440707110430p3d881d5fw5840a4a61d5cd633@mail.gmail.com> Doesn't "Furthermore, the BYDAY rule part MUST NOT be specified with a numeric value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part is specified" conflict with "The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY ... when the BYWEEKNO or BYMONTH rule parts are present." ? Other than that, the original wording makes more sense to me. It's saying that numeric BYDAY's are treated as weeks within the year when you've already specified a week within the month or you're filtering by month. It would be nice if it specified what BYDAY meant where FREQ=YEARLY and none of (BYMONTH,BYWEEKNO,BYYEARDAY are present, so I would prefer the last line read "when the BYMONTH rule part is not present". Specifically, I still don't see RRULE:FREQ=YEARLY;BYDAY=1MO fully specified. mike On 11/07/07, Andrew N Dowden wrote: > 3.3.10. Recurrence Rule > > .. The > numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY corresponds to an offset within the month when the BYMONTH > rule part is present, and corresponds to an offset within the year > when the BYWEEKNO or BYMONTH rule parts are present. > > Should the last line read?: > > .. BYWEEKNO or BYMONTHDAY rule parts .. > or > .. BYWEEKNO or BYYEARDAY rule parts .. > > Alternatively, does this make sense as is? > > -- > _______________________________________________ > > 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 Dave.Thewlis at calconnect.org Wed Jul 11 13:29:01 2007 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Wed Jul 11 13:30:07 2007 Subject: [Ietf-calsify] CalDAV Scheduling Requirements paper published by CalConnect Message-ID: <46953D8D.30109@calconnect.org> /CalDAV Scheduling Requirements V1.1/ has been published by the CalDAV Technical Committee of the Calendaring and Scheduling Consortium. It presents a list of features in the form of requirements for the scheduling extensions to CalDAV [RFC 4791], that is, the extensions to the Web Distributed Authoring and Versioning (WebDAV) [RFC 2518] protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC 2446]. The document is at http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf. -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) ? +1 707 498 2238 (mobile) http://www.calconnect.org ? Dave.Thewlis@calconnect.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070711/b09fc480/attachment.html From bernard.desruisseaux at oracle.com Wed Jul 11 18:34:50 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Jul 11 18:36:35 2007 Subject: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? In-Reply-To: <4694ACB1.2000805@softdesign.net.nz> References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> Message-ID: <4695853A.2030105@oracle.com> Ouch! I omited a single little word in the last sentence... when the BYWEEKNO or BYMONTH rule parts are *** NOT *** present. Sorry! Thanks, Bernard Andrew N Dowden wrote: > 3.3.10. Recurrence Rule > > .. The > numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY corresponds to an offset within the month when the BYMONTH > rule part is present, and corresponds to an offset within the year > when the BYWEEKNO or BYMONTH rule parts are present. > > Should the last line read?: > > .. BYWEEKNO or BYMONTHDAY rule parts .. > or > .. BYWEEKNO or BYYEARDAY rule parts .. > > Alternatively, does this make sense as is? > From bernard.desruisseaux at oracle.com Wed Jul 11 19:07:59 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Jul 11 19:09:18 2007 Subject: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? In-Reply-To: <178b8d440707110430p3d881d5fw5840a4a61d5cd633@mail.gmail.com> References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> <178b8d440707110430p3d881d5fw5840a4a61d5cd633@mail.gmail.com> Message-ID: <46958CFF.1000704@oracle.com> Mike Samuel wrote: > Doesn't > "Furthermore, the BYDAY rule part > MUST NOT be specified with a numeric value with the FREQ rule part > set to YEARLY when the BYWEEKNO rule part is specified" > conflict with > "The > numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY ... > when the BYWEEKNO or BYMONTH rule parts are present." > ? > > Other than that, the original wording makes more sense to me. It's > saying that numeric BYDAY's are treated as weeks within the year when > you've already specified a week within the month or you're filtering > by month. > > It would be nice if it specified what BYDAY meant where FREQ=YEARLY > and none of (BYMONTH,BYWEEKNO,BYYEARDAY are present, so I would prefer > the last line read > > "when the BYMONTH rule part is not present". +1 As I mentionned in my last mail, I had missed the "not". Furthermore, there is no need to mention BYWEEKNO here since the other statement forbids its use in this context. BTW, I don't consider issue 11 fully closed. During the last Jabber session we didn't go through all of Nigel's comment. Thanks, Bernard > > Specifically, I still don't see > RRULE:FREQ=YEARLY;BYDAY=1MO > fully specified. > > mike > > > > On 11/07/07, Andrew N Dowden wrote: >> 3.3.10. Recurrence Rule >> >> .. The >> numeric value in a BYDAY rule part with the FREQ rule part set to >> YEARLY corresponds to an offset within the month when the BYMONTH >> rule part is present, and corresponds to an offset within the year >> when the BYWEEKNO or BYMONTH rule parts are present. >> >> Should the last line read?: >> >> .. BYWEEKNO or BYMONTHDAY rule parts .. >> or >> .. BYWEEKNO or BYYEARDAY rule parts .. >> >> Alternatively, does this make sense as is? >> >> -- >> _______________________________________________ >> >> 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 >> > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From andrew_dowden at softdesign.net.nz Wed Jul 11 23:23:28 2007 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Wed Jul 11 23:24:37 2007 Subject: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? In-Reply-To: <4695853A.2030105@oracle.com> References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> <4695853A.2030105@oracle.com> Message-ID: <4695C8E0.4030404@softdesign.net.nz> Bernard Desruisseaux wrote: > Ouch! I omited a single little word in the last sentence... > > when the BYWEEKNO or BYMONTH rule parts are *** NOT *** present. > > Sorry! Thanks, that is what I hoped .. I was trying to determine preference between: RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3MO or RRULE:FREQ=YEARLY;MONTH=1;BYDAY=3MO and pondered the meaning (if any) of: RRULE:FREQ=YEARLY;BYDAY=3MO -- _______________________________________________ SoftDesign Group Dowden Software Associates P O Box 31 132, Lower Hutt 5040, NEW ZEALAND From lear at cisco.com Thu Jul 12 06:50:56 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Jul 12 06:52:05 2007 Subject: [Ietf-calsify] no jabber today or next week Message-ID: <469631C0.5070703@cisco.com> Please send your comments on RFC2445bis to the list at this point, and don't forget to consider changes to RFC2446bis. Thanks, Eliot From bernard.desruisseaux at oracle.com Fri Jul 13 12:33:40 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Fri Jul 13 12:36:31 2007 Subject: [Ietf-calsify] Working Group Last Call: draft-ietf-calsify-rfc2445bis-07.txt In-Reply-To: <4693315B.6000008@cisco.com> References: <4693315B.6000008@cisco.com> Message-ID: <4697D394.80307@oracle.com> Folks, I have uploaded the .html and .changes.html versions of the draft on the IETF Tools web site at the following locations: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.html http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html The .change.html version of the draft should help you figure out exactly what was changed in RFC 2445. Cheers, Bernard Eliot Lear wrote: > Dear all, > > Bernard has cranked out yet another iCalendar draft, and the chairs > would like to congratulate him on putting together an excellent > document, and thank him for his continued efforts. We would also like > to thank many contributors to improving this draft, including Cyrus > Daboo, Nigel Swinson, Jonathan Lennox, and Reinhold Kainhofer, just to > name a few (and apologies to those who I didn't list here). > > draft-ietf-calsify-rfc2445bis-07 represents over 80 issues worth of > changes, leaving open but a small handful. Previously, we have reviewed > the draft issue by issue. As the draft becomes available for your > review, we now ask a different question: is this draft ready for > publication as a Proposed Standard? What issues do you see that are > show stoppers? We ask that you consider this with the understanding > that best is often the enemy of great, and that it is difficult to > satisfy everyone in a "rough consensus" process. > > As such, we ask that you support the work that this group has done, > while taking the time to ensure that the work we have done here is > something we will be proud of years from now. And so we open Working > Group Last Call on this document. This last call will last for a month, > and end on August 10th, after which we will expect an updated draft to > address concerns raised. And so please note that this specification is > subject to change in the following ways, from this point forth: > > * Rough consensus for a change; these must be discussed on the list; > * Moving of small portions of normative text between this document > and rfc2446bis, as this group deems logical (these must be > discussed on this list); > * Changes required by shepherd review (I would expect these to be > very few in number); substantial ones must be discussed on this list; > * Changes required to clear IETF and IESG concerns; these should be > discussed on this list; and > * Insubstantial editorial corrections (nits); these can be sent > directly to the editor. > > Advancing a document through the IETF process is often like a tooth > extraction without pain killers. However, the process is designed to > promote technical quality. We the chairs will do our best to smooth the > process. > > Thank you all for your efforts to make this a great document. > > The Chairs > Aki Niemi > Eliot Lear > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -- Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696 Oracle Server Technologies 600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2 Bernard Desruisseaux | Chef senior du d?veloppement logiciel | 514.905.8696 Oracle Technologies serveurs 600, boul. de Maisonneuve Ouest, bureau 1900 | Montr?al (Qu?bec) H3A 3J2 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 7E14180ABF for ; Fri, 13 Jul 2007 12:36:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A41C14220C for ; Fri, 13 Jul 2007 12:35:35 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-50 required=4 tests=[AWL=0.463, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 iEB970iDvGmo for ; Fri, 13 Jul 2007 12:35:30 -0700 (PDT) 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 67FE81421F2 for ; Fri, 13 Jul 2007 12:35:30 -0700 (PDT) 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 l6DJZR62018489; Fri, 13 Jul 2007 14:35:27 -0500 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6DIcV8L027963; Fri, 13 Jul 2007 13:35:26 -0600 Received: from bdesruis-ca.ca.oracle.com by acsmt350.oracle.com with ESMTP id 3037410631184355232; Fri, 13 Jul 2007 12:33:52 -0700 Message-ID: <4697D394.80307@oracle.com> Date: Fri, 13 Jul 2007 15:33:40 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] Working Group Last Call: draft-ietf-calsify-rfc2445bis-07.txt References: <4693315B.6000008@cisco.com> In-Reply-To: <4693315B.6000008@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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, 13 Jul 2007 19:36:30 -0000 Folks, I have uploaded the .html and .changes.html versions of the draft on the IETF Tools web site at the following locations: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.html http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html The .change.html version of the draft should help you figure out exactly what was changed in RFC 2445. Cheers, Bernard Eliot Lear wrote: > Dear all, > > Bernard has cranked out yet another iCalendar draft, and the chairs > would like to congratulate him on putting together an excellent > document, and thank him for his continued efforts. We would also like > to thank many contributors to improving this draft, including Cyrus > Daboo, Nigel Swinson, Jonathan Lennox, and Reinhold Kainhofer, just to > name a few (and apologies to those who I didn't list here). > > draft-ietf-calsify-rfc2445bis-07 represents over 80 issues worth of > changes, leaving open but a small handful. Previously, we have reviewed > the draft issue by issue. As the draft becomes available for your > review, we now ask a different question: is this draft ready for > publication as a Proposed Standard? What issues do you see that are > show stoppers? We ask that you consider this with the understanding > that best is often the enemy of great, and that it is difficult to > satisfy everyone in a "rough consensus" process. > > As such, we ask that you support the work that this group has done, > while taking the time to ensure that the work we have done here is > something we will be proud of years from now. And so we open Working > Group Last Call on this document. This last call will last for a month, > and end on August 10th, after which we will expect an updated draft to > address concerns raised. And so please note that this specification is > subject to change in the following ways, from this point forth: > > * Rough consensus for a change; these must be discussed on the list; > * Moving of small portions of normative text between this document > and rfc2446bis, as this group deems logical (these must be > discussed on this list); > * Changes required by shepherd review (I would expect these to be > very few in number); substantial ones must be discussed on this list; > * Changes required to clear IETF and IESG concerns; these should be > discussed on this list; and > * Insubstantial editorial corrections (nits); these can be sent > directly to the editor. > > Advancing a document through the IETF process is often like a tooth > extraction without pain killers. However, the process is designed to > promote technical quality. We the chairs will do our best to smooth the > process. > > Thank you all for your efforts to make this a great document. > > The Chairs > Aki Niemi > Eliot Lear > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -- Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696 Oracle Server Technologies 600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2 Bernard Desruisseaux | Chef senior du développement logiciel | 514.905.8696 Oracle Technologies serveurs 600, boul. de Maisonneuve Ouest, bureau 1900 | Montréal (Québec) H3A 3J2 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 666928092A for ; Thu, 12 Jul 2007 06:52:04 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F132142204 for ; Thu, 12 Jul 2007 06:51:09 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-50 required=4 tests=[AWL=0.835, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 4Iy+Zr00lWfb for ; Thu, 12 Jul 2007 06:51:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 03FB31421FF for ; Thu, 12 Jul 2007 06:51:02 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2007 15:51:01 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABzPlUaQ/uCKh2dsb2JhbACBS41xAQEBCA4s X-IronPort-AV: i="4.16,533,1175464800"; d="scan'208"; a="147905023:sNHT140243670" 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 l6CDp1Gr004707 for ; Thu, 12 Jul 2007 15:51:01 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp578.cisco.com [10.61.66.66]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6CDp1TC004598 for ; Thu, 12 Jul 2007 13:51:01 GMT Message-ID: <469631C0.5070703@cisco.com> Date: Thu, 12 Jul 2007 15:50:56 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) 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=144; t=1184248261; x=1185112261; 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:=20no=20jabber=20today=20or=20next=20week |Sender:=20; bh=lKtYp1yRvECphfUjXjhCJXMGdGJDxyE2cxtG/0JfJhM=; b=rm0cTAKA5C0KJ7RBYxrCYHZTne+ar59kNCVLH9uR6uHpXn9VLzPoS/toK/02u+JX7x02OaFg 8fjhD64j3b9Jv743IfGNVWDsbSeay9T3QhtgG2MKKSY6QoiBaM1vrMWF; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] no jabber today or next week 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, 12 Jul 2007 13:52:04 -0000 Please send your comments on RFC2445bis to the list at this point, and don't forget to consider changes to RFC2446bis. Thanks, 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 6FE68808D6 for ; Wed, 11 Jul 2007 23:24:35 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5A1901421FD for ; Wed, 11 Jul 2007 23:23:40 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-50 required=4 tests=[AWL=1.218, BAYES_00=-2.599, UPPERCASE_25_50=0] 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 zv+wzs9ezZaN for ; Wed, 11 Jul 2007 23:23:33 -0700 (PDT) Received: from smtp17.ihug.co.nz (smtp17.ihug.co.nz [203.109.136.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 68CE61421FF for ; Wed, 11 Jul 2007 23:23:33 -0700 (PDT) Received: from cust.filter2.content.ihug.net.nz (smtp.mailfilter2.ihug.co.nz) [10.80.50.2] by akl-content-smtp17 with esmtp (Exim 4.60 #1 (Debian)) id 1I8s5K-0007gw-Q3; Thu, 12 Jul 2007 18:23:30 +1200 Ironport-Content-Filter: send-to-smtp Received: from 203-173-220-118.dialup.ihug.co.nz (HELO [127.0.0.1]) ([203.173.220.118]) by smtp.mailfilter2.ihug.co.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2007 18:23:31 +1200 Message-ID: <4695C8E0.4030404@softdesign.net.nz> Date: Thu, 12 Jul 2007 18:23:28 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-calsify Subject: Re: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> <4695853A.2030105@oracle.com> In-Reply-To: <4695853A.2030105@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, 12 Jul 2007 06:24:35 -0000 Bernard Desruisseaux wrote: > Ouch! I omited a single little word in the last sentence... > > when the BYWEEKNO or BYMONTH rule parts are *** NOT *** present. > > Sorry! Thanks, that is what I hoped .. I was trying to determine preference between: RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3MO or RRULE:FREQ=YEARLY;MONTH=1;BYDAY=3MO and pondered the meaning (if any) of: RRULE:FREQ=YEARLY;BYDAY=3MO -- _______________________________________________ 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 0EE0D80823 for ; Wed, 11 Jul 2007 19:09:10 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B1581421FB for ; Wed, 11 Jul 2007 19:08:15 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-50 required=4 tests=[AWL=0.472, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 9LN9Zy-hViMB for ; Wed, 11 Jul 2007 19:08:11 -0700 (PDT) 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 9C9D81421F6 for ; Wed, 11 Jul 2007 19:08:11 -0700 (PDT) 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 l6C2884Z011145; Wed, 11 Jul 2007 20:08:08 -0600 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6C1fd9B003443; Wed, 11 Jul 2007 20:08:07 -0600 Received: from dhcp-amer-rmdc-csvpn-gw6-141-144-112-19.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3032298191184206078; Wed, 11 Jul 2007 19:07:58 -0700 Message-ID: <46958CFF.1000704@oracle.com> Date: Wed, 11 Jul 2007 22:07:59 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mikesamuel@gmail.com Subject: Re: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> <178b8d440707110430p3d881d5fw5840a4a61d5cd633@mail.gmail.com> In-Reply-To: <178b8d440707110430p3d881d5fw5840a4a61d5cd633@mail.gmail.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 Cc: ietf-calsify 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, 12 Jul 2007 02:09:14 -0000 Mike Samuel wrote: > Doesn't > "Furthermore, the BYDAY rule part > MUST NOT be specified with a numeric value with the FREQ rule part > set to YEARLY when the BYWEEKNO rule part is specified" > conflict with > "The > numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY ... > when the BYWEEKNO or BYMONTH rule parts are present." > ? > > Other than that, the original wording makes more sense to me. It's > saying that numeric BYDAY's are treated as weeks within the year when > you've already specified a week within the month or you're filtering > by month. > > It would be nice if it specified what BYDAY meant where FREQ=YEARLY > and none of (BYMONTH,BYWEEKNO,BYYEARDAY are present, so I would prefer > the last line read > > "when the BYMONTH rule part is not present". +1 As I mentionned in my last mail, I had missed the "not". Furthermore, there is no need to mention BYWEEKNO here since the other statement forbids its use in this context. BTW, I don't consider issue 11 fully closed. During the last Jabber session we didn't go through all of Nigel's comment. Thanks, Bernard > > Specifically, I still don't see > RRULE:FREQ=YEARLY;BYDAY=1MO > fully specified. > > mike > > > > On 11/07/07, Andrew N Dowden wrote: >> 3.3.10. Recurrence Rule >> >> .. The >> numeric value in a BYDAY rule part with the FREQ rule part set to >> YEARLY corresponds to an offset within the month when the BYMONTH >> rule part is present, and corresponds to an offset within the year >> when the BYWEEKNO or BYMONTH rule parts are present. >> >> Should the last line read?: >> >> .. BYWEEKNO or BYMONTHDAY rule parts .. >> or >> .. BYWEEKNO or BYYEARDAY rule parts .. >> >> Alternatively, does this make sense as is? >> >> -- >> _______________________________________________ >> >> 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 >> > _______________________________________________ > 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 CFE5480822 for ; Wed, 11 Jul 2007 18:36:33 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B81341421F9 for ; Wed, 11 Jul 2007 18:35:38 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-50 required=4 tests=[AWL=0.482, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 iujkQZePYuLy for ; Wed, 11 Jul 2007 18:35:37 -0700 (PDT) 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 35C9A1421F6 for ; Wed, 11 Jul 2007 18:35:35 -0700 (PDT) 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 l6C1ZX7q013475; Wed, 11 Jul 2007 19:35:33 -0600 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6C19SEw029369; Wed, 11 Jul 2007 19:35:31 -0600 Received: from dhcp-amer-rmdc-csvpn-gw6-141-144-112-19.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3031134901184204088; Wed, 11 Jul 2007 18:34:48 -0700 Message-ID: <4695853A.2030105@oracle.com> Date: Wed, 11 Jul 2007 21:34:50 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Andrew N Dowden Subject: Re: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> In-Reply-To: <4694ACB1.2000805@softdesign.net.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: ietf-calsify 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, 12 Jul 2007 01:36:33 -0000 Ouch! I omited a single little word in the last sentence... when the BYWEEKNO or BYMONTH rule parts are *** NOT *** present. Sorry! Thanks, Bernard Andrew N Dowden wrote: > 3.3.10. Recurrence Rule > > .. The > numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY corresponds to an offset within the month when the BYMONTH > rule part is present, and corresponds to an offset within the year > when the BYWEEKNO or BYMONTH rule parts are present. > > Should the last line read?: > > .. BYWEEKNO or BYMONTHDAY rule parts .. > or > .. BYWEEKNO or BYYEARDAY rule parts .. > > Alternatively, does this make sense as is? > 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 39C7880708; Wed, 11 Jul 2007 13:30:05 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21BBB1421FD; Wed, 11 Jul 2007 13:29:10 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-50 required=4 tests=[AWL=0.007, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] 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 YPj3LobUNr+X; Wed, 11 Jul 2007 13:29:08 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 551CB1421FC; Wed, 11 Jul 2007 13:29:08 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I8io8-0005Qk-CE; Wed, 11 Jul 2007 13:29:08 -0700 Message-ID: <46953D8D.30109@calconnect.org> Date: Wed, 11 Jul 2007 13:29:01 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-caldav list , ietf-calsify list , ietf-calendar list Content-Type: multipart/alternative; boundary="------------090303050507070509070308" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] CalDAV Scheduling Requirements paper published by CalConnect X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 20:30:05 -0000 This is a multi-part message in MIME format. --------------090303050507070509070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit /CalDAV Scheduling Requirements V1.1/ has been published by the CalDAV Technical Committee of the Calendaring and Scheduling Consortium. It presents a list of features in the form of requirements for the scheduling extensions to CalDAV [RFC 4791], that is, the extensions to the Web Distributed Authoring and Versioning (WebDAV) [RFC 2518] protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC 2446]. The document is at http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf. -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------090303050507070509070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit CalDAV Scheduling Requirements V1.1 has been published by the CalDAV Technical Committee of the Calendaring and Scheduling Consortium. It presents a list of features in the form of requirements for the scheduling extensions to CalDAV [RFC 4791], that is, the extensions to the Web Distributed Authoring and Versioning (WebDAV) [RFC 2518] protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC 2446].   The document is at http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf.
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------090303050507070509070308-- 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 0060F80823 for ; Wed, 11 Jul 2007 04:31:25 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C1B641421FC for ; Wed, 11 Jul 2007 04:30:29 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-50 required=4 tests=[AWL=1.319, BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.231, SPF_PASS=-0.001] 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 WDPWS0iaB5MW for ; Wed, 11 Jul 2007 04:30:28 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF7BC1421F9 for ; Wed, 11 Jul 2007 04:30:27 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d30so373486and for ; Wed, 11 Jul 2007 04:30:27 -0700 (PDT) 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=F/T0+hE68jph6eYtkOfI1R9H4O4t1bqg4Iu1eeMmj/P/pvq+Smhvrqs/+oCAmiDARCnbITyZzIru46lskOV+ho3h7chzZrixMWOujWsU6P/j9yJxiTXmqa+WhjILWGRCpbUwV0nhjHmq965Y0iuoD3idk3j9naTFYlI/Vyya8e8= 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=YQVc6HhzoIFZ6/FxdhNuHWsE7RZ7Nttnd+y5P6jNSrRV9ZrGHQqwhU7x0FN6r5kcPIL+TtlrCh6YTgVFqdswZ46CECvFb2/GLF4D2cql1H7rAOQBMFuIiAb5B5VdNk9UcY5tOJbDI2GkTNitQNOicYrmaCSe2KWEary/jEc1h+c= Received: by 10.100.108.11 with SMTP id g11mr2705645anc.1184153427080; Wed, 11 Jul 2007 04:30:27 -0700 (PDT) Received: by 10.100.124.6 with HTTP; Wed, 11 Jul 2007 04:30:27 -0700 (PDT) Message-ID: <178b8d440707110430p3d881d5fw5840a4a61d5cd633@mail.gmail.com> Date: Wed, 11 Jul 2007 13:30:27 +0200 From: "Mike Samuel" To: "Andrew N Dowden" Subject: Re: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? In-Reply-To: <4694ACB1.2000805@softdesign.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4693315B.6000008@cisco.com> <4694ACB1.2000805@softdesign.net.nz> Cc: ietf-calsify 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, 11 Jul 2007 11:31:25 -0000 Doesn't "Furthermore, the BYDAY rule part MUST NOT be specified with a numeric value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part is specified" conflict with "The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY ... when the BYWEEKNO or BYMONTH rule parts are present." ? Other than that, the original wording makes more sense to me. It's saying that numeric BYDAY's are treated as weeks within the year when you've already specified a week within the month or you're filtering by month. It would be nice if it specified what BYDAY meant where FREQ=YEARLY and none of (BYMONTH,BYWEEKNO,BYYEARDAY are present, so I would prefer the last line read "when the BYMONTH rule part is not present". Specifically, I still don't see RRULE:FREQ=YEARLY;BYDAY=1MO fully specified. mike On 11/07/07, Andrew N Dowden wrote: > 3.3.10. Recurrence Rule > > .. The > numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY corresponds to an offset within the month when the BYMONTH > rule part is present, and corresponds to an offset within the year > when the BYWEEKNO or BYMONTH rule parts are present. > > Should the last line read?: > > .. BYWEEKNO or BYMONTHDAY rule parts .. > or > .. BYWEEKNO or BYYEARDAY rule parts .. > > Alternatively, does this make sense as is? > > -- > _______________________________________________ > > 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 9A48E80878 for ; Wed, 11 Jul 2007 03:12:04 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 813DB1421FC for ; Wed, 11 Jul 2007 03:11:09 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-50 required=4 tests=[AWL=1.233, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] 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 WU3aQl7NmmDn for ; Wed, 11 Jul 2007 03:11:07 -0700 (PDT) Received: from smtp10.ihug.co.nz (smtp10.ihug.co.nz [203.109.136.110]) by laweleka.osafoundation.org (Postfix) with ESMTP id EA57F1421F6 for ; Wed, 11 Jul 2007 03:11:04 -0700 (PDT) Received: from cust.filter2.content.ihug.net.nz (smtp.mailfilter2.ihug.co.nz) [10.80.50.2] by smtp10.ihug.co.nz with esmtp (Exim 4.60 #1 (Debian)) id 1I8Z9y-0002ds-5U; Wed, 11 Jul 2007 22:11:02 +1200 Ironport-Content-Filter: send-to-smtp Received: from 203-173-211-8.dialup.ihug.co.nz (HELO [127.0.0.1]) ([203.173.211.8]) by smtp.mailfilter2.ihug.co.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2007 22:11:01 +1200 Message-ID: <4694ACB1.2000805@softdesign.net.nz> Date: Wed, 11 Jul 2007 22:10:57 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-calsify References: <4693315B.6000008@cisco.com> In-Reply-To: <4693315B.6000008@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity? 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, 11 Jul 2007 10:12:04 -0000 3.3.10. Recurrence Rule .. The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. Should the last line read?: .. BYWEEKNO or BYMONTHDAY rule parts .. or .. BYWEEKNO or BYYEARDAY rule parts .. Alternatively, does this make sense as is? -- _______________________________________________ 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 8934A80A33 for ; Tue, 10 Jul 2007 12:52:41 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7031C1421FC for ; Tue, 10 Jul 2007 12:51:46 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-50 required=4 tests=[AWL=0.956, BAYES_00=-2.599] 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 TjyehBmZ15oi for ; Tue, 10 Jul 2007 12:51:44 -0700 (PDT) Received: from smtp.ucolick.org (hunan.ucolick.org [128.114.23.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C23E81421F9 for ; Tue, 10 Jul 2007 12:51:44 -0700 (PDT) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 813244231 for ; Tue, 10 Jul 2007 12:51:44 -0700 (PDT) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id 748CF3218 for ; Tue, 10 Jul 2007 12:51:44 -0700 (PDT) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.13.1/8.12.10) with ESMTP id l6AJpiq5011037 for ; Tue, 10 Jul 2007 12:51:44 -0700 Received: (from sla@localhost) by geneva.ucolick.org (8.13.1/8.13.1/Submit) id l6AJpeRo011036 for ietf-calsify@osafoundation.org; Tue, 10 Jul 2007 12:51:40 -0700 Date: Tue, 10 Jul 2007 12:51:39 -0700 From: Steve Allen To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt Message-ID: <20070710195139.GA10988@ucolick.org> References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> <20070710181208.GA10007@ucolick.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i 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, 10 Jul 2007 19:52:41 -0000 On Tue 2007-07-10T12:09:22 -0700, Ted Hardie hath writ: > Other IETF working groups have based their work on WGS-84, > and I'd suggest that one way forward it to state that WGS-84 > is the default datum. WGS-84 is more US-centric than is required by an international specification, especially given the expectation of the Galileo Terrestrial Reference Frame GTRF http://www.ggsp.eu/ggsp_gtrf.html At the level of 1 m any of them will do. Below the level of 1 m WGS-84 has changed and as of today does not produce the same results as it did a decade ago. This is geodetically akin to the leap second -- the reference point changed -- except that in the case of GEO the current language makes it clear that nobody cares. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m 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 DFC7380BE5 for ; Tue, 10 Jul 2007 12:10:23 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C270D1421F7 for ; Tue, 10 Jul 2007 12:09:28 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-50 required=4 tests=[AWL=1.061, BAYES_00=-2.599] 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 QO3ckZALw22F for ; Tue, 10 Jul 2007 12:09:26 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 439171421FC for ; Tue, 10 Jul 2007 12:09:26 -0700 (PDT) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6AJ9O8O006839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Jul 2007 12:09:25 -0700 Received: from [129.46.78.208] (carbuncle.qualcomm.com [129.46.78.208]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6AJ9NhB024191; Tue, 10 Jul 2007 12:09:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20070710181208.GA10007@ucolick.org> References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> <20070710181208.GA10007@ucolick.org> Date: Tue, 10 Jul 2007 12:09:22 -0700 To: Steve Allen , ietf-calsify@osafoundation.org From: Ted Hardie Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt Content-Type: text/plain; charset="us-ascii" 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, 10 Jul 2007 19:10:24 -0000 At 11:12 AM -0700 7/10/07, Steve Allen wrote: >On Tue 2007-07-10T19:38:03 +0200, Eliot Lear hath writ: >> Can you restate your point in a succinct >> proposed textual change? > >Not for sure. As written I don't know what it means nor how I would >come to agreement with other parties about what it means. > >If I give you my latitude and longitude based on the USGS topo >maps on my wall it will be off by 100 meters from the WGS-84 >coordinates in my .sig. Other IETF working groups have based their work on WGS-84, and I'd suggest that one way forward it to state that WGS-84 is the default datum. Parties could agree to interpret this field according to another datum, but would do so according to a private agreement outside this spec. Would that solve the problem? Ted >I'm not sure how exactly GEO is intended to be used, by machines >or humans, and I'm at a loss to reconcile the historical gotchas >other than by adding several sentences. > >In the absence of further input about how this is expected to be used >I suppose I would suggest something like this: > >The latitude and longitude MAY be expressed in any geodetic datum, but >if the application demands 1 meter precision then the parties >exchanging the information MUST agree on a particular datum. In the >absence of agreement the coordinates SHOULD be interpreted as any one >of ITRF, WGS-84, ETRF, or some other post-1980 satellite-based >geodetic datum (all of which agree at the level of 1 m). > >Here are some refs > >ITRF >http://itrf.ensg.ign.fr/ > >WGS-84 is defined for the US GPS system >http://en.wikipedia.org/wiki/WGS84 > >ETRS is a product of EUREF >http://lareg.ensg.ign.fr/EUREF/ > >-- >Steve Allen WGS-84 (GPS) >UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 >University of California Voice: +1 831 459 3046 Lng -122.06015 >Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m >_______________________________________________ >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 BD3AA80B47 for ; Tue, 10 Jul 2007 11:13:05 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A44AE1421FC for ; Tue, 10 Jul 2007 11:12:10 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-50 required=4 tests=[AWL=1.275, BAYES_00=-2.599] 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 ns4EyiPBFWBO for ; Tue, 10 Jul 2007 11:12:09 -0700 (PDT) Received: from smtp.ucolick.org (zilan.ucolick.org [128.114.23.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 013061421F2 for ; Tue, 10 Jul 2007 11:12:08 -0700 (PDT) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id B997D3404 for ; Tue, 10 Jul 2007 11:12:08 -0700 (PDT) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id B627B3401 for ; Tue, 10 Jul 2007 11:12:08 -0700 (PDT) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.13.1/8.12.10) with ESMTP id l6AIC8OA010127 for ; Tue, 10 Jul 2007 11:12:08 -0700 Received: (from sla@localhost) by geneva.ucolick.org (8.13.1/8.13.1/Submit) id l6AIC8uV010126 for ietf-calsify@osafoundation.org; Tue, 10 Jul 2007 11:12:08 -0700 Date: Tue, 10 Jul 2007 11:12:08 -0700 From: Steve Allen To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt Message-ID: <20070710181208.GA10007@ucolick.org> References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4693C3FB.2060500@cisco.com> User-Agent: Mutt/1.4.2.1i 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, 10 Jul 2007 18:13:05 -0000 On Tue 2007-07-10T19:38:03 +0200, Eliot Lear hath writ: > Can you restate your point in a succinct > proposed textual change? Not for sure. As written I don't know what it means nor how I would come to agreement with other parties about what it means. If I give you my latitude and longitude based on the USGS topo maps on my wall it will be off by 100 meters from the WGS-84 coordinates in my .sig. I'm not sure how exactly GEO is intended to be used, by machines or humans, and I'm at a loss to reconcile the historical gotchas other than by adding several sentences. In the absence of further input about how this is expected to be used I suppose I would suggest something like this: The latitude and longitude MAY be expressed in any geodetic datum, but if the application demands 1 meter precision then the parties exchanging the information MUST agree on a particular datum. In the absence of agreement the coordinates SHOULD be interpreted as any one of ITRF, WGS-84, ETRF, or some other post-1980 satellite-based geodetic datum (all of which agree at the level of 1 m). Here are some refs ITRF http://itrf.ensg.ign.fr/ WGS-84 is defined for the US GPS system http://en.wikipedia.org/wiki/WGS84 ETRS is a product of EUREF http://lareg.ensg.ign.fr/EUREF/ -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m 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 91C7D80B6A for ; Tue, 10 Jul 2007 10:43:42 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7720D1421FF for ; Tue, 10 Jul 2007 10:42:47 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-50 required=4 tests=[AWL=0.029, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] 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 UD0lASTzxlUa for ; Tue, 10 Jul 2007 10:42:45 -0700 (PDT) Received: from saraha.jackpot.uk.net (jackpot-adsl.demon.co.uk [80.177.236.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A20DC1421FC for ; Tue, 10 Jul 2007 10:42:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by saraha.jackpot.uk.net (Postfix) with ESMTP id 3E243733CD for ; Tue, 10 Jul 2007 18:42:42 +0100 (BST) Received: from saraha.jackpot.uk.net ([127.0.0.1]) by localhost (saraha.jackpot.uk.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idLLViADK9rf for ; Tue, 10 Jul 2007 18:42:41 +0100 (BST) Received: from [192.168.101.2] (unknown [192.168.101.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by saraha.jackpot.uk.net (Postfix) with ESMTP for ; Tue, 10 Jul 2007 18:42:41 +0100 (BST) Message-ID: <4693C5DB.2000308@jackpot.uk.net> Date: Tue, 10 Jul 2007 18:46:03 +0100 From: "Mr. Demeanour" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> <4693C3FB.2060500@cisco.com> In-Reply-To: <4693C3FB.2060500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 10 Jul 2007 17:43:42 -0000 Eliot Lear wrote: > Steve, > > Thanks for your comment. Can you restate your point in a succinct > proposed textual change? If I read it correctly, it doesn't call for a textual change. It's simply pointing out that six decimal places/one meter may be spurious precision (one could add prose to that effect, of course). > > Eliot > > Steve Allen wrote: >> In the context of metrology I wonder about the text in 3.8.1.6. >> Geographic Position >> >> It says The longitude and latitude values MAY be specified up to >> six decimal places, which will allow for accuracy to within one >> meter of geographical position. >> >> This is only true if the geodetic datum is specified. >> >> I point out the US DoD's instructional page to soldiers on this >> http://earth-info.nima.mil/GandG/publications/horizdatum.html >> >> At a more technical level I point out the partial list of datums in >> use at >> http://earth-info.nima.mil/GandG/publications/tm8358.1/tr83581b.html#ZZ23 >> where in the links to the graphics for table 2 it is immediately >> evident that some older geodetic datums upon which available maps >> are based differ by hundreds of meters from the more recent, >> satellite-geodesy-based datums. >> >> In much the same vein as quoting the standards documents for UTC, >> if the values used in this field are to be believed at a level of 1 >> meter, then it is at the least necessary to require that the >> latitude and longitude values be expressed in a standard geodetic >> datum created no earlier than the year 1980. >> >> -- Steve Allen >> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room >> 165 Lat +36.99855 University of California Voice: +1 831 459 >> 3046 Lng -122.06015 Santa Cruz, CA 95064 >> http://www.ucolick.org/~sla/ Hgt +250 m 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 ED4CA80B6A for ; Tue, 10 Jul 2007 10:39:10 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D40D9142203 for ; Tue, 10 Jul 2007 10:38:15 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-50 required=4 tests=[AWL=0.848, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 KlADZPDq7lYJ for ; Tue, 10 Jul 2007 10:38:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 98C091421FF for ; Tue, 10 Jul 2007 10:38:13 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2007 19:38:14 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANdgk0aQ/uCKh2dsb2JhbACPNwEBCQ4s X-IronPort-AV: i="4.16,523,1175464800"; d="scan'208"; a="147710926:sNHT26989410" 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 l6AHcCFj008316; Tue, 10 Jul 2007 19:38:12 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp230.cisco.com [10.61.64.230]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6AHc6TC024592; Tue, 10 Jul 2007 17:38:09 GMT Message-ID: <4693C3FB.2060500@cisco.com> Date: Tue, 10 Jul 2007 19:38:03 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Steve Allen Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt References: <4693315B.6000008@cisco.com> <20070710173146.GA9772@ucolick.org> In-Reply-To: <20070710173146.GA9772@ucolick.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=1844; t=1184089092; x=1184953092; 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]=20GEO=20in=20draft-ietf-calsify-rfc244 5bis-07.txt |Sender:=20; bh=dgVRUxoJciiR/hGb2irY/5iN/uFpUlrryBn3Y0ygf+Q=; b=U8hhFQI6AYYlWB22fH14Z/EZH+IaqWKqz5v8bcNfXXetCXCM5THKOQ3AV/3PiFB72df8zFMq 64jwPmW2dcRsIFpSd2fkBnOh48/0OM931xC5HkxkmjHJfjgb3VG1Zk57; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 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: Tue, 10 Jul 2007 17:39:11 -0000 Steve, Thanks for your comment. Can you restate your point in a succinct proposed textual change? Eliot Steve Allen wrote: > In the context of metrology I wonder about the text in > 3.8.1.6. Geographic Position > > It says > The longitude and > latitude values MAY be specified up to six decimal places, which > will allow for accuracy to within one meter of geographical > position. > > This is only true if the geodetic datum is specified. > > I point out the US DoD's instructional page to soldiers on this > http://earth-info.nima.mil/GandG/publications/horizdatum.html > > At a more technical level I point out the partial list of datums in > use at > http://earth-info.nima.mil/GandG/publications/tm8358.1/tr83581b.html#ZZ23 > where in the links to the graphics for table 2 it is immediately > evident that some older geodetic datums upon which available maps are > based differ by hundreds of meters from the more recent, > satellite-geodesy-based datums. > > In much the same vein as quoting the standards documents for UTC, if > the values used in this field are to be believed at a level of 1 > meter, then it is at the least necessary to require that the latitude > and longitude values be expressed in a standard geodetic datum created > no earlier than the year 1980. > > -- > Steve Allen WGS-84 (GPS) > UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 > University of California Voice: +1 831 459 3046 Lng -122.06015 > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m > _______________________________________________ > 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 9FD8080B5E for ; Tue, 10 Jul 2007 10:32:52 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6C26B1421FF for ; Tue, 10 Jul 2007 10:31:57 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-50 required=4 tests=[AWL=1.913, BAYES_00=-2.599] 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 jHwUaFaUGldb for ; Tue, 10 Jul 2007 10:31:51 -0700 (PDT) Received: from smtp.ucolick.org (zilan.ucolick.org [128.114.23.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B993D1421FC for ; Tue, 10 Jul 2007 10:31:51 -0700 (PDT) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 63D41338C for ; Tue, 10 Jul 2007 10:31:51 -0700 (PDT) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id 55FBA1A23 for ; Tue, 10 Jul 2007 10:31:51 -0700 (PDT) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.13.1/8.12.10) with ESMTP id l6AHVpZk009839 for ; Tue, 10 Jul 2007 10:31:51 -0700 Received: (from sla@localhost) by geneva.ucolick.org (8.13.1/8.13.1/Submit) id l6AHVkoh009838 for ietf-calsify@osafoundation.org; Tue, 10 Jul 2007 10:31:46 -0700 Date: Tue, 10 Jul 2007 10:31:46 -0700 From: Steve Allen To: ietf-calsify@osafoundation.org Message-ID: <20070710173146.GA9772@ucolick.org> References: <4693315B.6000008@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4693315B.6000008@cisco.com> User-Agent: Mutt/1.4.2.1i Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.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: Tue, 10 Jul 2007 17:32:52 -0000 In the context of metrology I wonder about the text in 3.8.1.6. Geographic Position It says The longitude and latitude values MAY be specified up to six decimal places, which will allow for accuracy to within one meter of geographical position. This is only true if the geodetic datum is specified. I point out the US DoD's instructional page to soldiers on this http://earth-info.nima.mil/GandG/publications/horizdatum.html At a more technical level I point out the partial list of datums in use at http://earth-info.nima.mil/GandG/publications/tm8358.1/tr83581b.html#ZZ23 where in the links to the graphics for table 2 it is immediately evident that some older geodetic datums upon which available maps are based differ by hundreds of meters from the more recent, satellite-geodesy-based datums. In much the same vein as quoting the standards documents for UTC, if the values used in this field are to be believed at a level of 1 meter, then it is at the least necessary to require that the latitude and longitude values be expressed in a standard geodetic datum created no earlier than the year 1980. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m 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 01B5380BD3; Tue, 10 Jul 2007 00:13:33 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D8A1A1421FF; Tue, 10 Jul 2007 00:12:37 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-50 required=4 tests=[AWL=0.174, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, HTML_10_20=1.351, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ZXTQfCdWbYny; Tue, 10 Jul 2007 00:12:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F1271421F9; Tue, 10 Jul 2007 00:12:35 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2007 09:12:33 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOLNkkaQ/uCLh2dsb2JhbACCKzeJXoJzAQEBCA4s X-IronPort-AV: i="4.16,520,1175464800"; d="scan'208,217"; a="147631694:sNHT2641923002" 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 l6A7CWvH022424; Tue, 10 Jul 2007 09:12:32 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp230.cisco.com [10.61.64.230]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6A7CVTC004367; Tue, 10 Jul 2007 07:12:31 GMT Message-ID: <4693315B.6000008@cisco.com> Date: Tue, 10 Jul 2007 09:12:27 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: multipart/alternative; boundary="------------000704080604000100050705" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5303; t=1184051552; x=1184915552; 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:=20Working=20Group=20Last=20Call=3A=20draft-ietf-calsify-rfc2445 bis-07.txt |Sender:=20; bh=5v/qNNKVRvsI5GPML5q5Myk0iaM9hJK72U/+uN86HY4=; b=Uk5fqszPchi7VA/6diGdMxAHjMi6mgQxrqIdxvRnfu2y9o7osN/o3GCY4yol888FBm9XhJMV PwhvVUF2BBvAYMr+ZbDfh8dh0vCVtHZe19ED/KUdUCQkwgyHRqNJxVVB; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); Subject: [Ietf-calsify] Working Group Last Call: draft-ietf-calsify-rfc2445bis-07.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: Tue, 10 Jul 2007 07:13:33 -0000 This is a multi-part message in MIME format. --------------000704080604000100050705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Bernard has cranked out yet another iCalendar draft, and the chairs would like to congratulate him on putting together an excellent document, and thank him for his continued efforts. We would also like to thank many contributors to improving this draft, including Cyrus Daboo, Nigel Swinson, Jonathan Lennox, and Reinhold Kainhofer, just to name a few (and apologies to those who I didn't list here). draft-ietf-calsify-rfc2445bis-07 represents over 80 issues worth of changes, leaving open but a small handful. Previously, we have reviewed the draft issue by issue. As the draft becomes available for your review, we now ask a different question: is this draft ready for publication as a Proposed Standard? What issues do you see that are show stoppers? We ask that you consider this with the understanding that best is often the enemy of great, and that it is difficult to satisfy everyone in a "rough consensus" process. As such, we ask that you support the work that this group has done, while taking the time to ensure that the work we have done here is something we will be proud of years from now. And so we open Working Group Last Call on this document. This last call will last for a month, and end on August 10th, after which we will expect an updated draft to address concerns raised. And so please note that this specification is subject to change in the following ways, from this point forth: * Rough consensus for a change; these must be discussed on the list; * Moving of small portions of normative text between this document and rfc2446bis, as this group deems logical (these must be discussed on this list); * Changes required by shepherd review (I would expect these to be very few in number); substantial ones must be discussed on this list; * Changes required to clear IETF and IESG concerns; these should be discussed on this list; and * Insubstantial editorial corrections (nits); these can be sent directly to the editor. Advancing a document through the IETF process is often like a tooth extraction without pain killers. However, the process is designed to promote technical quality. We the chairs will do our best to smooth the process. Thank you all for your efforts to make this a great document. The Chairs Aki Niemi Eliot Lear --------------000704080604000100050705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear all,

Bernard has cranked out yet another iCalendar draft, and the chairs would like to congratulate him on putting together an excellent document, and thank him for his continued efforts.  We would also like to thank many contributors to improving this draft, including Cyrus Daboo, Nigel Swinson, Jonathan Lennox, and Reinhold Kainhofer, just to name a few (and apologies to those who I didn't list here).

draft-ietf-calsify-rfc2445bis-07 represents over 80 issues worth of changes, leaving open but a small handful.  Previously, we have reviewed the draft issue by issue.  As the draft becomes available for your review, we now ask a different question: is this draft ready for publication as a Proposed Standard?  What issues do you see that are show stoppers?  We ask that you consider this with the understanding that best is often the enemy of great, and that it is difficult to satisfy everyone in a "rough consensus" process.

As such, we ask that you support the work that this group has done, while taking the time to ensure that the work we have done here is something we will be proud of years from now.  And so we open Working Group Last Call on this document.  This last call will last for a month, and end on August 10th, after which we will expect an updated draft to address concerns raised.  And so please note that this specification is subject to change in the following ways, from this point forth:
  • Rough consensus for a change; these must be discussed on the list;
  • Moving of small portions of normative text between this document and rfc2446bis, as this group deems logical (these must be discussed on this list);
  • Changes required by shepherd review (I would expect these to be very few in number); substantial ones must be discussed on this list;
  • Changes required to clear IETF and IESG concerns; these should be discussed on this list; and
  • Insubstantial editorial corrections (nits); these can be sent directly to the editor.
Advancing a document through the IETF process is often like a tooth extraction without pain killers.  However, the process is designed to promote technical quality.  We the chairs will do our best to smooth the process.

Thank you all for your efforts to make this a great document.

The Chairs
Aki Niemi
Eliot Lear --------------000704080604000100050705-- 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 D2AB480BBD for ; Tue, 10 Jul 2007 00:04:58 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B99FD1421FB for ; Tue, 10 Jul 2007 00:04:03 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-50 required=4 tests=[AWL=0.857, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 CzYMdm9aj5Ci for ; Tue, 10 Jul 2007 00:04:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 389771421F9 for ; Tue, 10 Jul 2007 00:04:01 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2007 09:04:00 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAPMkkaQ/uCLh2dsb2JhbACPMwEBAQgOLA X-IronPort-AV: i="4.16,520,1175464800"; d="scan'208"; a="147630997:sNHT22609654" 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 l6A73xeF020384 for ; Tue, 10 Jul 2007 09:03:59 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp230.cisco.com [10.61.64.230]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6A73xTC002241 for ; Tue, 10 Jul 2007 07:03:59 GMT Message-ID: <46932F5B.9000706@cisco.com> Date: Tue, 10 Jul 2007 09:03:55 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) 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=167; t=1184051039; x=1184915039; 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:=20draft=20agenda |Sender:=20; bh=kQ0bbLj+Irt15hQxltKh/7J6RF8y4eu5lsZYy9JgcG4=; b=A7iA0cl6Up+ZZ6xCltkthrMqjlIXFAYN6P6ywzkRCNzyXdwZSK3Nob58XfcvDSPsZp+1KfqB 8/Uv9/bJsqAid/DW6xubCcum+g+Id8Gb6N9mU4P914HraSYcN6hPwvC7; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); Subject: [Ietf-calsify] draft agenda 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, 10 Jul 2007 07:04:58 -0000 1. Agenda Bashing (1 minute) 2. Administrativia (Chairs - 3 minutes) 3. RFC2445bis Status (Chairs - 5 minutes) 4. RFC2446bis Discussion (Cyrus - the rest) 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 976A180AE8 for ; Mon, 9 Jul 2007 14:15:59 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7A0631421FB for ; Mon, 9 Jul 2007 14:15:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-50 required=4 tests=[AWL=0.525, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BOUND_NEXTPART=0.278, NO_REAL_NAME=0.961] 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 HhF8lbBtXh+E for ; Mon, 9 Jul 2007 14:15:03 -0700 (PDT) Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C7F821421FC for ; Mon, 9 Jul 2007 14:15:02 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DA41626E90; Mon, 9 Jul 2007 21:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I80ZR-0008S5-Pc; Mon, 09 Jul 2007 17:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 17:15:01 -0400 Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-07.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: Mon, 09 Jul 2007 21:16:00 -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 : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Author(s) : B. Desruisseaux Filename : draft-ietf-calsify-rfc2445bis-07.txt Pages : 177 Date : 2007-7-9 This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to- dos, journal entries and free/busy information, independent of any particular calendar service or protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-07.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-rfc2445bis-07.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-rfc2445bis-07.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-7-9155906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsify-rfc2445bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9155906.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 8333380AF0 for ; Mon, 9 Jul 2007 04:08:10 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 62448142206 for ; Mon, 9 Jul 2007 04:07:15 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-50 required=4 tests=[AWL=0.866, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 blaLuwf99a+U for ; Mon, 9 Jul 2007 04:07:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7A9BF142201 for ; Mon, 9 Jul 2007 04:07:13 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2007 13:07:12 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAO6zkUaQ/uCLh2dsb2JhbACBTI1rAQEJDiw X-IronPort-AV: i="4.16,516,1175464800"; d="scan'208"; a="147557383:sNHT832652288" 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 l69B7Bxw012220 for ; Mon, 9 Jul 2007 13:07:11 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4200.cisco.com [10.61.80.103]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l69B7BTC027545 for ; Mon, 9 Jul 2007 11:07:11 GMT Message-ID: <469216DC.5040401@cisco.com> Date: Mon, 09 Jul 2007 13:07:08 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) 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=57; t=1183979232; x=1184843232; 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:=20tracker=20is=20back=20up |Sender:=20; bh=CiFpWuFtwyyTZngVTKnwcXGXHJ+2wLfuDpFrYbvgyqg=; b=cHfnoCsL4qTFYvrqzZxR096ot7OT1uMeOiO1sylxk73wEL66AvqlH4YrUoYukC8tWPCMerb4 zNkviZ9qCMneS7BObQ3OCXrd7c5fsu4QKudLUG1M1P0UenoAnz5jMyRD; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); Subject: [Ietf-calsify] tracker is back up 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, 09 Jul 2007 11:08:10 -0000 http://www.ofcourseimright.com/cgi-bin/roundup/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 8CBBB809D6; Fri, 6 Jul 2007 18:34:25 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A57114220A; Fri, 6 Jul 2007 18:33:30 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-50 required=4 tests=[AWL=0.006, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] 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 obOYGUaaxi7x; Fri, 6 Jul 2007 18:33:27 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CC8241421F7; Fri, 6 Jul 2007 18:33:27 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.100]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I6zAw-0005Ob-LC; Fri, 06 Jul 2007 18:33:30 -0700 Message-ID: <468EED65.6010806@calconnect.org> Date: Fri, 06 Jul 2007 18:33:25 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-calendar list , ietf-calsify list , ietf-caldav list Content-Type: multipart/alternative; boundary="------------030804020304020806040400" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] My apologies for multiple CalConnect-related postings X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2007 01:34:25 -0000 This is a multi-part message in MIME format. --------------030804020304020806040400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I seem to have screwed up somehow and posted our announcement of the vCard workshop and possibly the next Roundtable multiple times to at least one of these lists. And to make it worse, many people are subscribed to two or more of them, and thus got an unnecessary flood of repeats. I apologize for the mistake, however it occurred, and will do my best to not do it again. I hope that the irritant didn't overcome the messages! Apologies again, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------030804020304020806040400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I seem to have screwed up somehow and posted our announcement of the vCard workshop and possibly the next Roundtable multiple times to at least one of these lists.

And to make it worse, many people are subscribed to two or more of them, and thus got an unnecessary flood of repeats.

I apologize for the mistake, however it occurred, and will do my best to not do it again.  I hope that the irritant didn't overcome the messages!

Apologies again,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------030804020304020806040400-- 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 42F198084A for ; Fri, 6 Jul 2007 10:18:22 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1DC33142210 for ; Fri, 6 Jul 2007 10:17:27 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-50 required=4 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 KmOahn3K7ZOy for ; Fri, 6 Jul 2007 10:17:23 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 292E214220A for ; Fri, 6 Jul 2007 10:17:23 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I6rQq-00065q-5Z; Fri, 06 Jul 2007 10:17:24 -0700 Message-ID: <468E791A.4010508@calconnect.org> Date: Fri, 06 Jul 2007 10:17:14 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: calconnect-l Reflector , ietf-calsify list Content-Type: multipart/alternative; boundary="------------000102050701090000030408" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2007 17:18:22 -0000 This is a multi-part message in MIME format. --------------000102050701090000030408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit CalConnect invites you to a a one-day open workshop on vCard and what should be done about it on Tuesday, September 18, 2007, at M.I.T. in Cambridge, Massachusetts. This event is _open_ to vendors, customers, CalConnect members and non-members alike. There is no fee, but you _must_ register in advance and numbers are limited. Please see http://www.calconnect.org/vcardworkshop.shtml for more information and links to the registration and logistics pages, a general discussion list about the workshop, and a questionnaire to give us more guidance to make the workshop as productive as possible. From the workshop introduction page: vCard is a well established standard for representing and transferring contact information on computer systems and mobile devices. Having been in use for a while, a number of areas of the specification have been noted as problematic and in need of revision for fixes or enhancements. To that end, CalConnect (the Calendaring & Scheduling Consortium) is hosting a one day vCard-focused workshop event at M.I.T. in Cambridge, Massachusetts in September with the goal of bringing together the key players to help move forward vCard revision efforts. Note that an effort is already under way at the IETF (Internet Engineering Task Force) to develop a personal address book access protocol based on the CardDAV specification, and since that is based on vCard, a revision of the vCard specification will be taking place within the IETF. However, bringing together interested parties in a focused discussion at a workshop can help drive that effort and provide supporting input to it to ensure the specific needs of the key players is covered. The goal of the workshop is two-fold. First to determine the real interest in revising the vCard specification, and second to determine what needs to be revised and how to go about doing that. If you are not a CalConnect member, this is also an opportunity to stay on for Roundtable X as an observer, and we'd be delighted to have you; you will have to register separately for the Roundtable. Regardless of whether or not you are interested in attending the workshop, we would appreciate it very much if you would take a few minutes to fill out the questionnaire , as this will help provide the workshop participants with guidance as to the directions any progression on vCard should take. -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------000102050701090000030408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit CalConnect invites you to a a one-day open workshop on vCard and what should be done about it on Tuesday, September 18, 2007, at M.I.T. in Cambridge, Massachusetts. This event is open to vendors, customers, CalConnect members and non-members alike. There is no fee, but you must register in advance and numbers are limited. Please see
http://www.calconnect.org/vcardworkshop.shtml for more information and links to the registration and logistics pages, a general discussion list about the workshop, and a questionnaire to give us more guidance to make the workshop as productive as possible.

>From the workshop introduction page:

vCard is a well established standard for representing and transferring contact information on computer systems and mobile devices. Having been in use for a while, a number of areas of the specification have been noted as problematic and in need of revision for fixes or enhancements. To that end, CalConnect (the Calendaring & Scheduling Consortium) is hosting a one day vCard-focused workshop event at M.I.T. in Cambridge, Massachusetts in September with the goal of bringing together the key players to help move forward vCard revision efforts.

Note that an effort is already under way at the IETF (Internet Engineering Task Force) to develop a personal address book access protocol based on the CardDAV specification, and since that is based on vCard, a revision of the vCard specification will be taking place within the IETF. However, bringing together interested parties in a focused discussion at a workshop can help drive that effort and provide supporting input to it to ensure the specific needs of the key players is covered.

The goal of the workshop is two-fold. First to determine the real interest in revising the vCard specification, and second to determine what needs to be revised and how to go about doing that.


If you are not a CalConnect member, this is also an opportunity to stay on for Roundtable X as an observer, and we'd be delighted to have you; you will have to register separately for the Roundtable. 

Regardless of whether or not you are interested in attending the workshop, we would appreciate it very much if you would take a few minutes to fill out the questionnaire, as this will help provide the workshop participants with guidance as to the directions any progression on vCard should take.


--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------000102050701090000030408-- 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 1217D7F54A for ; Fri, 6 Jul 2007 09:52:01 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E081714220A for ; Fri, 6 Jul 2007 09:51:05 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-50 required=4 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 uwCOxi318CgV for ; Fri, 6 Jul 2007 09:51:01 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E9349142207 for ; Fri, 6 Jul 2007 09:51:01 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I6r1K-0003sa-P7; Fri, 06 Jul 2007 09:51:02 -0700 Message-ID: <468E72ED.8000602@calconnect.org> Date: Fri, 06 Jul 2007 09:50:53 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-calsify list Content-Type: multipart/alternative; boundary="------------060007090201050100040500" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] Announcing CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2007 16:52:01 -0000 This is a multi-part message in MIME format. --------------060007090201050100040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit *The Calendaring and Scheduling Consortium announces Roundtable X and IOP Test Event *CalConnect would like to invite you to our Roundtable X and the associated CalConnect Interoperability Test Event, the week of September 17-21, 2007, in Cambridge, Massachusetts, hosted by M.I.T. Registration is now open for the Roundtable and/or the IOP test event. Logistics and registration information may be found at http://www.calconnect.org/roundtable10.shtml and at http://www.calconnect.org/iopseptember2007.shtml General schedule: The IOP test will begin at noon Monday and run through noon Wednesday. The Roundtable will begin at lunch on Wednesday and run through lunch on Friday. We plan to offer optional practicums on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on Wednesday morning prior to lunch. The IOP test event will involve both CalDAV and regular iCalendar, iMIP and iTIP interoperability testing scenarios. In addition, plans and preliminary work for a Mobile Calendar IOP Test Event, and the scenarios associated with that event, will be covered. Roundtables are largely comprised of technical committee sessions, which generally include reports on work accomplished or in progress, working sessions in a "committee of the whole" environment for all interested parties, and discussions about work to be undertaken. Time is also set aside for BOFs either scheduled in advance, or impromptu at the meeting. If you are not currently a member of the Consortium, you may attend a single Roundtable, or a single IOP test event, as an observer; see http://www.calconnect.org/observer.shtml for more information. Both members and non-members may participate in the IOP test events. If you think you might attend, it is advisable to book your hotel room early -- hotel rooms in Cambridge in September are hard to come by. For more information, please call or e-mail me as below. See you in Cambridge! Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------060007090201050100040500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Calendaring and Scheduling Consortium announces Roundtable X and  IOP Test Event

CalConnect would like to invite you to our Roundtable X and the associated CalConnect Interoperability Test Event, the week of September 17-21, 2007, in Cambridge, Massachusetts, hosted by M.I.T.  Registration is now open for the Roundtable and/or the IOP test event.  Logistics and registration information may be found at http://www.calconnect.org/roundtable10.shtml and at http://www.calconnect.org/iopseptember2007.shtml

General schedule:  The IOP test will begin at noon Monday and run through noon Wednesday.  The Roundtable will begin at lunch on Wednesday and run through lunch on Friday.  We plan to offer optional practicums on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on Wednesday morning prior to lunch. 

The IOP test event will involve both CalDAV and regular iCalendar, iMIP and iTIP interoperability testing scenarios.  In addition, plans and preliminary work for a Mobile Calendar IOP Test Event, and the scenarios associated with that event, will be covered.

Roundtables are largely comprised of technical committee sessions, which generally include reports on work accomplished or in progress, working sessions in a "committee of the whole" environment for all interested parties, and discussions about work to be undertaken.  Time is also set aside for BOFs either scheduled in advance, or impromptu at the meeting.

If you are not currently a member of the Consortium, you may attend a single Roundtable, or a single IOP test event, as an observer; see http://www.calconnect.org/observer.shtml for more information.

Both members and non-members may participate in the IOP test events.

If you think you might attend, it is advisable to book your hotel room early -- hotel rooms in Cambridge in September are hard to come by.

For more information, please call or e-mail me as below.

See you in Cambridge!

Dave Thewlis

--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------060007090201050100040500-- 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 012578086A for ; Thu, 5 Jul 2007 19:28:47 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4D61B142211 for ; Thu, 5 Jul 2007 19:27:52 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-50 required=4 tests=[AWL=0.233, BAYES_00=-2.599] 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 HzrdDyR1WSwJ for ; Thu, 5 Jul 2007 19:27:50 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 10F55142210 for ; Thu, 5 Jul 2007 19:27:49 -0700 (PDT) Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l662RlM9032341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jul 2007 22:27:48 -0400 Date: Thu, 05 Jul 2007 22:27:48 -0400 From: Cyrus Daboo To: Calsify Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========052CEC7FF3409C7C28B1==========" Subject: [Ietf-calsify] Updated recurrence rule table 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, 06 Jul 2007 02:28:48 -0000 --==========052CEC7FF3409C7C28B1========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi folks, During today's jabber session we discussed in detail Nigel Swinson's comments on the recurrence rule table I posted a while back. Whilst we have not gone through all his comments, there were some obvious fixes to the table and notes that needed to be done, and those are attached to this message. You can see the full discussion at: . -- Cyrus Daboo --==========052CEC7FF3409C7C28B1========== Content-Type: text/plain; charset=utf-8; name="RRULEs processing" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="RRULEs processing"; size=5439 RRULE Processing A particular BYxxx rule part may expand or limit the set of date/times = generated by the rule. The expand or limit behaviour is governed by the = FREQ value used for the rule. Example: RRULE:FREQ=3DMONTHLY;BYMONTH=3D1,3,5;BYDAY=3DMO,TU The FREQ=3DMONTHLY value would match each of the twelve months in a year. The BYMONTH=3D1,3,5 rule part limits the matching months to just the 1st, 3rd and 5th in a year. The BYDAY=3DMO,TU rule part adds each Monday and Tuesday within the matching months to the recurrence set. The table below shows the dependency of BYxxx rule part expand or limit = behaviour on the FREQ value in the rule. When evaluating a rule, each BYxxx = rule part MUST be evaluated in the order it appears in the table (i.e. = BYMONTH evaluated before BYWEEKNO), irrespective of the expand or limit = behaviour. The term "N/A" means that the corresponding BYxxx rule part MUST NOT be = used with the corresponding FREQ value. BYDAY has some special behaviour depending on the FREQ value and this is = described in separate notes below the table. +--------------------------------------------------------------------------+= | |SECONDLY|MINUTELY| HOURLY | DAILY | WEEKLY | MONTHLY | YEARLY = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYMONTH | Limit | Limit | Limit | Limit | Limit | Limit | Expand = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYWEEKNO | Limit | Limit | Limit | Limit | Limit | N/A | Expand = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYYEARDAY | Limit | Limit | Limit | N/A | N/A | N/A | Expand = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYMONTHDAY| Limit | Limit | Limit | Limit | N/A | Expand | Expand = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYDAY | Limit | Limit | Limit | Limit | Note 1 | Note 2 | Note 3 = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYHOUR | Limit | Limit | Limit | Expand | Expand | Expand | Expand = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYMINUTE | Limit | Limit | Expand | Expand | Expand | Expand | Expand = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYSECOND | Limit | Expand | Expand | Expand | Expand | Expand | Expand = | |----------+--------+--------+--------+--------+--------+---------+--------|= |BYSETPOS | Limit | Limit | Limit | Limit | Limit | Limit | Limit = | +----------+--------+--------+--------+--------+--------+---------+--------+= +--------------------------------------------------------------------+ | Note 1 | Special expand for WEEKLY. | | | | | | A BYDAY rule part cannot have a numeric value in a | | | FREQ=3DWEEKLY rule (i.e. 'MO', 'TU' etc is allowed, but | | | '1MO', '2TU' is not allowed). | | | | +--------+-----------------------------------------------------------| | Note 2 | Limit if BYMONTHDAY is present, otherwise special expand | | | for MONTHLY. | | | | | | The numeric value in a BYDAY rule part in a FREQ=3DMONTHLY | | | rule corresponds to an offset within the month. | | | | +--------+-----------------------------------------------------------| | Note 3 | Limit if BYYEARDAY or BYMONTHDAY is present, | | | otherwise special expand for WEEKLY if BYWEEKNO present, | | | otherwise special expand for MONTHLY if BYMONTH present, | | | otherwise special expand for YEARLY. | | | | | | A BYDAY rule part cannot have a numeric value in a | | | FREQ=3DYEARLY rule (i.e. 'MO', 'TU' etc is allowed, but | | | '1MO', '2TU' is not allowed), if BYWEEKNO is specified. | | | | | | The numeric value in a BYDAY rule part in a FREQ=3DYEARLY | | | rule with a BYMONTH present corresponds to an offset | | | within the month. | | | | | | The numeric value in a BYDAY rule part in a FREQ=3DYEARLY | | | rule without BYWEEKNO or BYMONTH present corresponds to | | | an offset within the year. | | | | +--------+-----------------------------------------------------------+ --==========052CEC7FF3409C7C28B1==========-- 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 5CD2780827 for ; Thu, 5 Jul 2007 13:53:48 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30E04142210 for ; Thu, 5 Jul 2007 13:52:53 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-50 required=4 tests=[AWL=0.524, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 2XdfabcsBYB3 for ; Thu, 5 Jul 2007 13:52:49 -0700 (PDT) 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 7C160142202 for ; Thu, 5 Jul 2007 13:52:49 -0700 (PDT) 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 l65KqaHu019353; Thu, 5 Jul 2007 15:52:37 -0500 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l65KqaVw031422; Thu, 5 Jul 2007 14:52:36 -0600 Received: from bdesruis-ca.ca.oracle.com by acsmt350.oracle.com with ESMTP id 3014591001183668689; Thu, 05 Jul 2007 13:51:29 -0700 Message-ID: <468D59CE.1020801@oracle.com> Date: Thu, 05 Jul 2007 16:51:26 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring References: <46338F68.5040700@oracle.com> <468C7ACF.3030604@oracle.com> In-Reply-To: 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 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: Thu, 05 Jul 2007 20:53:48 -0000 Cyrus Daboo wrote: > Hi Bernard, > > --On July 5, 2007 12:59:59 AM -0400 Bernard Desruisseaux > wrote: > >> New text: >> >> > Purpose: In the case of an iCalendar object that specifies a >> > "METHOD" property, this property specifies the date and time that >> > the instance of the iCalendar object was created. In the case of >> > an iCalendar object that doesn't specify a "METHOD" property, this >> > property specifies the date and time that the information >> > associated with the calendar component was last revised in the >> > calendar store. > > Well "calendar store" is not defined anywhere. I'm simply using the same terminology that is used in RFC 2445 when describing the "LAST-MODIFIED" property. > Plus if I happen to use > iCalendar format as the native format in my calendar store this would > not hold true - i.e. DTSTAMP would not change when the calendar data > changed. Whoever changes the iCalendar object should change the value of the DTSTAMP property. If a calendar user agent modifies an iCalendar object in its local calendar store it should update the value of DTSTAMP. When a CalDAV client modifies an iCalendar object and uploads it to a CalDAV server it should update the value of the DTSTAMP property before uploading it to the server. Whether iCalendar is used as the native format in your calendar store does not matter. > > I am also a little unsure of what "created" means in the METHOD case. Again, I simply used the same terminology that is used in RFC 2445. > For instance, in at least one implementation I have done I create the > iTIP message for an event by copying that event. Are you saying that > when that happens a new DTSTAMP must be used? My understanding is that DTSTAMP should be set to the time when a iTIP messages is created/generated/rendered. > If so, I think the term > "generated" might be better than "created". I agree. We should update the description of LAST-MODIFIED as well. > Or we should be much more > explicit. In fact perhaps iTIP should state that every new iTIP message, > be it a PUBLISH, REQUEST, REPLY etc MUST have a new DTSTAMP generated > for it. Ok. > If we go down that route then maybe 2445 needs to say nothing > about DTSTAMP + METHOD. But then how would DTSTAMP differ from LAST-MODIFIED in RFC2445? 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 3EB8D807E4 for ; Thu, 5 Jul 2007 07:15:19 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 14F86142213 for ; Thu, 5 Jul 2007 07:14:24 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_ID=1.393] 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 DAmc8Kqd6N5t for ; Thu, 5 Jul 2007 07:14:21 -0700 (PDT) Received: from alnrmhc15.comcast.net (alnrmhc15.comcast.net [206.18.177.55]) by laweleka.osafoundation.org (Postfix) with ESMTP id 80C49142210 for ; Thu, 5 Jul 2007 07:14:21 -0700 (PDT) Received: from thare (c-71-203-100-120.hsd1.wa.comcast.net[71.203.100.120]) by comcast.net (alnrmhc15) with SMTP id <20070705141420b1500cgfope>; Thu, 5 Jul 2007 14:14:20 +0000 From: "Tim Hare" To: "'Bernard Desruisseaux'" , "'Calsify WG'" Subject: RE: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMPin the context of calendaring Date: Thu, 5 Jul 2007 10:14:49 -0400 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: Ace+wXXw9gEAxZJHRM+dJHAMZH61ugAOZpiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <468C7ACF.3030604@oracle.com> Message-Id: <20070705141421.80C49142210@laweleka.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, 05 Jul 2007 14:15:19 -0000 Sorry I can't make Jabber sessions, but here is an alternative text idea regarding DTSTAMP. Old text: > Purpose: The property indicates the date/time that the instance > of the iCalendar object was created. New text: > Purpose: This property is used to determine the correct version of an iCalendar > object to use, when presented with two different versions of the same object. For > example, two iTIP REQUESTs to change meeting time for the same meeting arrive, > or two different files with METHOD:PUBLISH are found describing the same events. > The object with the later DTSTAMP identifies the most recent copy and MUST be used. With this new text, I would leave the old text about CREATED and LAST-MODIFIED alone. Tim Hare Interested Bystander, Non-Inc. 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 8D43380759 for ; Thu, 5 Jul 2007 06:58:10 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 64E6A142210 for ; Thu, 5 Jul 2007 06:57:15 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-50 required=4 tests=[AWL=0.907, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 XHqdcVyseqdL for ; Thu, 5 Jul 2007 06:57:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C15D142213 for ; Thu, 5 Jul 2007 06:57:09 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2007 15:57:08 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMqVjEaQ/uCKh2dsb2JhbACBS41iAQEBCA4s X-IronPort-AV: i="4.16,503,1175464800"; d="scan'208"; a="147323793:sNHT25076172" 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 l65Dv8CN010096 for ; Thu, 5 Jul 2007 15:57:08 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp499.cisco.com [10.61.65.243]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65Dv7TC004243 for ; Thu, 5 Jul 2007 13:57:08 GMT Message-ID: <468CF8B2.1060807@cisco.com> Date: Thu, 05 Jul 2007 15:57:06 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) 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=25; t=1183643828; x=1184507828; 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:=20jabber=20starts=20shortly |Sender:=20; bh=6CVPxcLSiaE3VU2Xzd9YUIVDthiKSoWdy9ZfiHd0jAI=; b=QIUrNP5jl0hIzmIaJbvtyC8waHhyrmNfIWursM/DAGeBZGU+IcgEcHIE4vZzH1AkYxIo0rrl AOv4aZkfVtk4YUBT2saqKB5bhoWwN9bJ8TPTvONZ02BCyIgY+7RjKNhl; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] jabber starts shortly 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, 05 Jul 2007 13:58:10 -0000 calsify@jabber.ietf.org 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 5EE7A802A2 for ; Thu, 5 Jul 2007 06:24:39 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 358A114221D for ; Thu, 5 Jul 2007 06:23:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-50 required=4 tests=[AWL=0.353, BAYES_00=-2.599] 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 UbxRL-n8AhJe for ; Thu, 5 Jul 2007 06:23:41 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 06E99142213 for ; Thu, 5 Jul 2007 06:23:40 -0700 (PDT) Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l65DNS8N028242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 09:23:31 -0400 Date: Thu, 05 Jul 2007 09:23:23 -0400 From: Cyrus Daboo To: Bernard Desruisseaux , Calsify WG Subject: Re: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring Message-ID: In-Reply-To: <468C7ACF.3030604@oracle.com> References: <46338F68.5040700@oracle.com> <468C7ACF.3030604@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-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, 05 Jul 2007 13:24:39 -0000 Hi Bernard, --On July 5, 2007 12:59:59 AM -0400 Bernard Desruisseaux wrote: > New text: > > > Purpose: In the case of an iCalendar object that specifies a > > "METHOD" property, this property specifies the date and time that > > the instance of the iCalendar object was created. In the case of > > an iCalendar object that doesn't specify a "METHOD" property, this > > property specifies the date and time that the information > > associated with the calendar component was last revised in the > > calendar store. Well "calendar store" is not defined anywhere. Plus if I happen to use iCalendar format as the native format in my calendar store this would not hold true - i.e. DTSTAMP would not change when the calendar data changed. I am also a little unsure of what "created" means in the METHOD case. For instance, in at least one implementation I have done I create the iTIP message for an event by copying that event. Are you saying that when that happens a new DTSTAMP must be used? If so, I think the term "generated" might be better than "created". Or we should be much more explicit. In fact perhaps iTIP should state that every new iTIP message, be it a PUBLISH, REQUEST, REPLY etc MUST have a new DTSTAMP generated for it. If we go down that route then maybe 2445 needs to say nothing about DTSTAMP + METHOD. -- 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 58ADC80679 for ; Wed, 4 Jul 2007 22:01:44 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FAAB142202 for ; Wed, 4 Jul 2007 22:00:49 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-50 required=4 tests=[AWL=0.535, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 O45cXUMT59ry for ; Wed, 4 Jul 2007 22:00:44 -0700 (PDT) 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 AC37F142207 for ; Wed, 4 Jul 2007 22:00:44 -0700 (PDT) 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 l6550f6P020401 for ; Thu, 5 Jul 2007 00:00:42 -0500 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6550eFQ027520 for ; Wed, 4 Jul 2007 23:00:41 -0600 Received: from dhcp-amer-rmdc-csvpn-gw5-141-144-105-126.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3012300751183611601; Wed, 04 Jul 2007 22:00:01 -0700 Message-ID: <468C7ACF.3030604@oracle.com> Date: Thu, 05 Jul 2007 00:59:59 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Calsify WG Subject: Re: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring References: <46338F68.5040700@oracle.com> In-Reply-To: <46338F68.5040700@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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, 05 Jul 2007 05:01:44 -0000 Here's the exact text change for this proposal. Old text: > Purpose: The property indicates the date/time that the instance > of the iCalendar object was created. New text: > Purpose: In the case of an iCalendar object that specifies a > "METHOD" property, this property specifies the date and time that > the instance of the iCalendar object was created. In the case of > an iCalendar object that doesn't specify a "METHOD" property, this > property specifies the date and time that the information > associated with the calendar component was last revised in the > calendar store. Old text: > This property is different than the "CREATED" and "LAST-MODIFIED" > properties. These two properties are used to specify when the > particular calendar data in the calendar store was created and last > modified. This is different than when the iCalendar object > representation of the calendar service information was created or > last modified. New text: > In the case of an iCalendar object that specifies a "METHOD" > property, this property is different than the "CREATED" and "LAST- > MODIFIED" properties. These two properties are used to specify > when the particular calendar data in the calendar store was > created and last modified. This is different than when the > iCalendar object representation of the calendar service > information was created or last modified. > > In the case of an iCalendar object that doesn't specify a "METHOD" > property, this property is equivalent to the "LAST-MODIFIED" > property. Cheers, Bernard Bernard Desruisseaux wrote: > In section 4.8.7.2 Date/Time Stamp of RFC 2445 it says: > > > Purpose: The property indicates the date/time that the instance of > > the iCalendar object was created. > > > > [...] > > > > Description: The value MUST be specified in the UTC time format. > > > > This property is also useful to protocols such as [IMIP] that have > > inherent latency issues with the delivery of content. This property > > will assist in the proper sequencing of messages containing iCalendar > > objects. > > > > This property is different than the "CREATED" and "LAST-MODIFIED" > > properties. These two properties are used to specify when the > > particular calendar data in the calendar store was created and last > > modified. This is different than when the iCalendar object > > representation of the calendar service information was created or > > last modified. > > As was discussed at the Calsify WG meeting in Prague, I believe we > need to clarify the purpose of the "DTSTAMP" property. > > I believe the current definition of the "DTSTAMP" property make > sense in the context of scheduling, but not so for calendaring > (i.e., calendar access). > > According to the current definition, a CalDAV server that doesn't > store the iCalendar representation of calendar resources should > always return iCalendar objects with the "DTSTAMP" property set to > the current time with the consequence that the ETag (see section > 3.11 Entity Tags of RFC 2616) of all the calendar resources would > change every second! Clearly, no serious CalDAV server implementation > would do such a thing. Returning iCalendar objects with the "DTSTAMP" > property set to the last modification time of the calendar resource > would seem more appropriate. > > One way to address this issue would be to make the "DTSTAMP" property > optional in all calendar components in the iCalendar specifications, > but to make it mandatory in all calendar components in the iTIP > specification. Actually, it might have been the original intent. > RFC 2445 was ambiguous on whether "DTSTAMP" is mandatory or optional. > (see issues 37, 38, 39 and 40). iTIP, on the other hand, was clear > that "DTSTAMP" is required in all calendar components. > > In my opinion, we should not go back on the consensus made earlier > by this WG to clarify that "DTSTAMP" is required in all calendar > components. Some calendaring applications may actually find it useful > to always have a "DTSTAMP" property in all calendar components. > Remember that the "LAST-MODIFIED" property is optional in all calendar > components. > > In order to address this issue in a way that preserves backward > compatibility with existing iCalendar applications, I propose to > modify the definition of the "DTSTAMP" property to specify that in > the context of calendaring (i.e., iCalendar object with no "METHOD" > property) its value may be set to the date and time that the calendar > component was last revised in the calendar store (i.e., same > definition as LAST-MODIFIED), but that in the context of scheduling > its value should be set to the date and time where the scheduling > message (i.e., iCalendar object with a METHOD property) was created. > > Cheers, > Bernard > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -- Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696 Oracle Server Technologies 600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2 Bernard Desruisseaux | Chef senior du développement logiciel | 514.905.8696 Oracle Technologies serveurs 600, boul. de Maisonneuve Ouest, bureau 1900 | Montréal (Québec) H3A 3J2 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 D1BDF8062A for ; Wed, 4 Jul 2007 13:20:51 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A72BD142204 for ; Wed, 4 Jul 2007 13:19:56 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-50 required=4 tests=[AWL=1.185, BAYES_00=-2.599] 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 7+9hcJieL40W for ; Wed, 4 Jul 2007 13:19:52 -0700 (PDT) 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 4A7DD142201 for ; Wed, 4 Jul 2007 13:19:52 -0700 (PDT) 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 l64KJn9V020416 for ; Wed, 4 Jul 2007 22:19:49 +0200 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: Should we bring back the RANGE parameter? Date: Wed, 4 Jul 2007 22:19:45 +0200 User-Agent: KMail/1.9.5 + Features References: <468BC0D9.5010807@oracle.com> In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707042219.48835.reinhold@kainhofer.com> 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, 04 Jul 2007 20:20:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 4. Juli 2007 schrieb Cyrus Daboo: > Hi Bernard, > > --On July 4, 2007 11:46:33 AM -0400 Bernard Desruisseaux > > wrote: > > At the last Jabber session you said you were tempted to bring back the > > RANGE parameter to allow an Organizer to cancel all future recurrence > > instances of a recurring component defined with an unbounded RRULE. Apart from the technical issues and the semantics, looking at a practical point: How many calendaring applications and server have implemented or might be using the RANGE concept now or in the future? 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) iD8DBQFGjADkTqjEwhXvPN0RAonEAJ9X9qxFkQ+GeFXObNhtXVWhG2meawCgjtLs Ubowh1UbRCUv96CYVSDsYQA= =RJpU -----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 E19EA805ED for ; Wed, 4 Jul 2007 13:16:27 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B6205142204 for ; Wed, 4 Jul 2007 13:15:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-50 required=4 tests=[AWL=0.916, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 1zOxgk9ycWg0 for ; Wed, 4 Jul 2007 13:15:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id D9238142201 for ; Wed, 4 Jul 2007 13:15:30 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Jul 2007 22:15:30 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACqci0aQ/uCKh2dsb2JhbACBS41eAQEJDiw X-IronPort-AV: i="4.16,499,1175464800"; d="scan'208"; a="147254364:sNHT26032282" 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 l64KFTcI019584; Wed, 4 Jul 2007 22:15:29 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4612.cisco.com [10.61.82.3]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l64KFSTC017120; Wed, 4 Jul 2007 20:15:29 GMT Message-ID: <468BFFE0.7010704@cisco.com> Date: Wed, 04 Jul 2007 22:15:28 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Bernard Desruisseaux , "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=101; t=1183580129; x=1184444129; 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:=20tracker=20is=20down=20for=20now |Sender:=20; bh=dvsGIGUA4avS1rpKjWqQ6l5Shhiu7qsOyFHPOnRi6JM=; b=Dk8DZ9vaQid9IF1nNZuJvwZa5lZi8IaUhPU/GgOgpCrbEz2kD2fMk/hA+DNjh3Eem3HrVuHa 8S+njNnoDgqOG+BjwYGBB/K3oYI0pk80mTJG9vI28TSLpv4SPrNz+jdh; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] tracker is down for now 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, 04 Jul 2007 20:16:28 -0000 i've had database problems. i am still working to get them up. apologies for the inconvenience. 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 8EC7F80617 for ; Wed, 4 Jul 2007 12:18:09 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 627A0142204 for ; Wed, 4 Jul 2007 12:17:14 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-50 required=4 tests=[AWL=0.244, BAYES_00=-2.599] 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 XE8ohwRiVLBX for ; Wed, 4 Jul 2007 12:17:12 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 56CE9142202 for ; Wed, 4 Jul 2007 12:17:12 -0700 (PDT) Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l64JH5j6023112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 15:17:05 -0400 Date: Wed, 04 Jul 2007 15:17:04 -0400 From: Cyrus Daboo To: Bernard Desruisseaux Message-ID: In-Reply-To: <468BC0D9.5010807@oracle.com> References: <468BC0D9.5010807@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 Cc: Calsify WG Subject: [Ietf-calsify] Re: Should we bring back the RANGE parameter? 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, 04 Jul 2007 19:18:09 -0000 Hi Bernard, --On July 4, 2007 11:46:33 AM -0400 Bernard Desruisseaux wrote: > At the last Jabber session you said you were tempted to bring back the > RANGE parameter to allow an Organizer to cancel all future recurrence > instances of a recurring component defined with an unbounded RRULE. > > While I understand that most applications don't handle arbitrary > modifications to the RRULE property nicely, I believe it shouldn't > be difficult to handle truncation of unbounded RRULE properly with > the simple addition of a COUNT or UNTIL rule part. There is a semantic difference between sending a REQUEST that changes a rule vs sending a CANCEL to remove instances. Consider: an existing event with a series of overridden instances. The attendee's client will have the master event stored with the rrule, plus all the instances. Now the Organizer sends out a CANCEL that uses RANGE - in that case it is obvious that any overridden instances whose RECURRENCE-ID overlaps the RANGE are to be removed. Now consider the alternative you propose: in that case the Organizer has to send not only the modified master event with the RRULE but also ALL overridden instances that are not being cancelled. That would be very inefficient. So the important thing here is that its better to update a recurring event in iTIP by sending diffs. As soon as you try and change the rule you have to send out the entire set of valid instances. CANCEL, ADD and a REQUEST that uses RECURRENCE-ID are effectively "diffs" to the original set. In any case it is not just CANCEL that is an issue here. A more common case is an ongoing meeting where the location changes, or where an attendee is added or removed and those changes are ongoing. How do you do that without RANGE=THISANDFUTURE? I realize that there are issues with multiple RANGE's in the same event set, but how else can we support a use case like this? I believe that we can pin down the semantics of RANGE=THISANDFUTURE enough to do what we need (I don't care about THISANDPRIOR). -- 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 5584A80501 for ; Wed, 4 Jul 2007 08:48:52 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 29E6114220C for ; Wed, 4 Jul 2007 08:47:57 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-50 required=4 tests=[AWL=0.547, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 qRqBBakN9MRp for ; Wed, 4 Jul 2007 08:47:54 -0700 (PDT) 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 988F314220A for ; Wed, 4 Jul 2007 08:47:54 -0700 (PDT) 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 l64FlhIp001400; Wed, 4 Jul 2007 09:47:43 -0600 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l64F5gkx026710; Wed, 4 Jul 2007 09:47:43 -0600 Received: from dhcp-amer-rmdc-csvpn-gw6-141-144-113-32.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3012129361183563998; Wed, 04 Jul 2007 08:46:38 -0700 Message-ID: <468BC0D9.5010807@oracle.com> Date: Wed, 04 Jul 2007 11:46:33 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Cyrus Daboo 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 Cc: Calsify WG Subject: [Ietf-calsify] Should we bring back the RANGE parameter? 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, 04 Jul 2007 15:48:52 -0000 Cyrus, At the last Jabber session you said you were tempted to bring back the RANGE parameter to allow an Organizer to cancel all future recurrence instances of a recurring component defined with an unbounded RRULE. While I understand that most applications don't handle arbitrary modifications to the RRULE property nicely, I believe it shouldn't be difficult to handle truncation of unbounded RRULE properly with the simple addition of a COUNT or UNTIL rule part. In my opinion, this would be much simpler than trying to address the 4 issues that were raised with the RANGE parameter in the following thread: http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001239.html and, more importantly, expect applications to support it. Cheers, Bernard