Subject: [ietf-calsify] Fw: Re: Fw: Re: EXRULE Question

From: Adrian Crum <[email-masked]>
Date: Thu, 20 Nov 2008 07:58:34 -0800 (PST)

Oops, I did it again.

--- On Thu, 11/20/08, Adrian Crum <[email-masked]> wrote:

> From: Adrian Crum <[email-masked]>
> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question
> To: "Cyrus Daboo" <[email-masked]>
> Date: Thursday, November 20, 2008, 7:58 AM
> Many thanks to everyone who replied!
> 
> I'm late bringing this subject up because I didn't
> discover it until recently. I was working on integrating
> iCalendar with an open source ERP program and when certain
> CUAs didn't accept the program's output I ended up
> here.
> 
> I spent two days reading through the Calcify documentation
> and archives, so I know this effort has been a struggle for
> everyone involved.
> 
> During my research I could see right away that EXRULE was
> not the problem, it was DTSTART. DTSTART is ambiguous, not
> EXRULE.
> 
> Anyway, I'll accept the draft as-is. I would be
> interested in participating in the discussion of a potential
> "iCalendar V3." I'm not an expert on the RFC,
> but I have experience coding calendar software - so I'm
> not a novice either.
> 
> -Adrian
> 
> 
> --- On Thu, 11/20/08, Cyrus Daboo <[email-masked]>
> wrote:
> 
> > From: Cyrus Daboo <[email-masked]>
> > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question
> > To: [email-masked],
> [email-masked]
> > Date: Thursday, November 20, 2008, 7:07 AM
> > Hi Adrian,
> > 
> > --On November 19, 2008 9:36:18 PM -0800 Adrian Crum
> > <[email-masked]> wrote:
> > 
> > > I disagree that it is hard to implement. The
> original
> > RFC was clear and
> > > easy to implement:
> > 
> > Actually it was not clear. Without restating all the
> > discussion we had before on this, there are some clear
> > ambiguities in the spec that meant interpretation of
> EXRULE
> > was up to the implementer. Just because you
> implemented it
> > in a way that works for your data does not mean it
> will work
> > the same way in some other product/library.
> > 
> > As an example, the original spec states in the EXRULE
> > definition: "The "DTSTART" defines the
> first
> > instance in the recurrence set.". The (correct)
> reading
> > of this is that an EXRULE will always exclude the
> first
> > instance in any recurrence set. This means, if you
> really
> > don't want the first instance cancelled, you have
> to
> > adjust the event in some way to create a fake
> > "first" instance that is OK to cancel, and
> then
> > hope the rule does not match the second etc but in
> doing
> > that you may break the behavior of RRULEs also
> present.
> > 
> > That is just one example of ambiguity and lack of
> clarity.
> > Whilst it might have been possible to tighten up the
> > definitions like this, the WG looked not only looked
> at
> > these ambiguities but also at how widely the feature
> was
> > supported and used (interoperably)  and then came to
> > consensus on removal.
> > 
> > -- Cyrus Daboo

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

---

From: Reinhold Kainhofer <[email-masked]>
Date: Thu, 20 Nov 2008 18:04:45 +0100

> not the problem, it was DTSTART. DTSTART is ambiguous, not

Actually, it was not DTSTART, either, but rather a side-comment on the COUNT 
attribute for RRULE, which messed things up:

"   The COUNT rule part defines the number of occurrences at which to
   range-bound the recurrence. The "DTSTART" property value, if
   specified, counts as the first occurrence."

The problem was that most people read that last sentence as "The DTSTART is 
always the first occurrence of a recurrence rule". While in my opinion it 
simply meant "If the DTSTART matches the rule, it counts as one occurrence 
for the purpose of calculating the end date using the COUNT value."
The reason why such a clarifying (yeah, I agree it didn't meet its purpose!) 
sentence was needed was that the generation of the whole recurrence set was 
defined as DTSTART + all occurrences generated by RRULE +..., but already 
existing times are not added a second time. So, if the DTSTART matched the 
rule, it would not be added to the recurrence rule again, but it would count 
towards COUNT.
If you interpret it like this, then suddenly all those problems with RRULE and 
EXRULE vanish and things just work.

Anyway, the possible confusion about DTSTART being always generated (by the 
wrong interpretation of the quoted sentence) by an RRULE, even if it doesn't 
match the rule, is now solved in rfc2445bis by the requirement that the RRULE 
should always match the DTSTART.

And I completely agree with the others that EXRULE was hardly ever used, and I 
don't know a single application that provides a GUI way to handle EXRULEs at 
all.
Sure, you can't represent some events any more (but the same can be said about 
the new requirement of having at most one RRULE), but I don't see this as a 
real showstopper, as there have always been some events that cannot be 
represented (even with full RRULE/EXRULE power), like the US election day.

So, I don't have any problem with EXRULE being deprecated. I see more problems 
with forbidding multiple RRULEs, but even that is no big deal to me.

Cheers,
Reinhold

> > > supported and used (interoperably)  and then came to

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Nov 2008 12:23:28 -0500

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Actually, you've picked a bad example here!

See: http://tools.ietf.org/html/rfc2445#page-124

Easter, for instance, would have been a good example.

Cheers,
Bernard

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFJJZiuTqjEwhXvPN0RApQmAKCNJuZWP+tQGovrMzv533KNIddPTwCfd+mr
> aouDgT59yRjwkeGWBVKBwWA=
> =QdiS
> -----END PGP SIGNATURE-----

Date: Thu, 20 Nov 2008 12:23:28 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-calsify] Fw: Re:  Fw: Re: EXRULE Question

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Actually, you've picked a bad example here!

See: http://tools.ietf.org/html/rfc2445#page-124

Easter, for instance, would have been a good example.

Cheers,
Bernard

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFJJZiuTqjEwhXvPN0RApQmAKCNJuZWP+tQGovrMzv533KNIddPTwCfd+mr
> aouDgT59yRjwkeGWBVKBwWA=
> =QdiS
> -----END PGP SIGNATURE-----

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked], [email-masked]
Date: Thu, 20 Nov 2008 18:04:45 +0100
Subject: Re: [ietf-calsify] Fw: Re:  Fw: Re: EXRULE Question

Cheers,
Reinhold

- -- 

Date: Thu, 20 Nov 2008 17:09:39 +0100
From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: [ietf-calsify] [Fwd: Re:  Fw: Re: EXRULE Question]

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

For some silly reason now I didn't CC the group.  Duh...

--------------000303030605050206050200
Content-Type: message/rfc822;
 name="Re: [ietf-calsify] Fw: Re: EXRULE Question.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Re: [ietf-calsify] Fw: Re: EXRULE Question.eml"

X-Mozilla-Keys: 
Message-ID: <[email-masked]>
Date: Thu, 20 Nov 2008 11:21:33 +0100
From: Eliot Lear <[email-masked]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081118 Shredder/3.0b1pre
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

WG Chair hat on.

We are well past working group last call (it occurred prior to summer). 
Aside from editorial nits there should be no further changes to this 
document, as we are now suffering from "great is the enemy of good".  
Bernard, all other changes at this point should be handled after 
IETF-wide last call.

Adrian, I encourage you to accept the document as it is, given that 
you've had quite a while to provide feedback prior to last call.

Eliot

On 11/20/08 6:36 AM, Adrian Crum wrote:
> Ben,
>
> Thanks for the reply.
>
> I disagree that it is hard to implement. The original RFC was clear and easy to implement:
>
> 1. Create a union of all RDATEs and RRULEs
> 2. Create a union of all EXDATEs and EXRULEs
> 3. Create a difference of the two unions
>
> I know this is easy to implement because I've done it. My example works with the original RFC. I challenge anyone to prove that it doesn't work with the original RFC.
>
> Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS the original.
>
> That is the point I am trying to make. Calcify isn't just simplifying or clarifying the spec, it is breaking it.
>
> -Adrian
>
>
>
> --- On Wed, 11/19/08, Ben Fortuna<[email-masked]>  wrote:
>
>    
>> From: Ben Fortuna<[email-masked]>
>> To: [email-masked]
>> Cc: [email-masked]
>> Date: Wednesday, November 19, 2008, 9:24 PM
>> Adrian,
>>
>> I think you'll find it was removed as it is hard to
>> implement, meaning that
>> many CUAs either didn't support it or had a broken
>> implementation.
>>
>> It should be possible to write some code that converts a
>> recurrence rule to
>> a list of  dates in a specified period (see iCal4j), so
>> from there it
>> shouldn't be hard to convert an EXRULE to a list of
>> EXDATES, and if you
>> choose a large enough period of time it should achieve the
>> same effect
>> (albeit a bit more verbose).
>>
>> Once the new RFC is approved I might investigate supporting
>> automatic
>> conversion of deprecated properties, so things like this
>> should ultimately
>> be transparent.
>>
>> regards,
>> ben
>>
>>
>> On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum
>>> Oops, I meant for this to go to the mailing list.
>>>
>>>
>>> --- On Wed, 11/19/08, Adrian Crum
>>>        
>>>> From: Adrian Crum<[email-masked]>
>>>> Subject: Re: [ietf-calsify] EXRULE Question
>>>> To: "Bernard Desruisseaux"
>>>>          
>> <[email-masked]>
>>      
>>>> Date: Wednesday, November 19, 2008, 8:26 PM
>>>> Thank you for the reply!
>>>>
>>>> That is very disappointing. Now I'm forced to
>>>>          
>> define a
>>      
>>>> finite amount of discreet dates for exclusions
>>>>          
>> instead of
>>      
>>>> specifying a few rules.
>>>>
>>>> I was better off with the original specification.
>>>>
>>>> Other than "no one is using EXRULE" -
>>>>          
>> what is the
>>      
>>>> compelling reason to remove it from the RFC? Is
>>>>          
>> everyone in
>>      
>>>> calcify that sure that it will never be used?
>>>>
>>>> I thought the objective was to simplify and
>>>>          
>> clarify the
>>      
>>>> RFC, not cripple it.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> --- On Wed, 11/19/08, Bernard Desruisseaux
>>>> <[email-masked]>  wrote:
>>>>
>>>>          
>>>>> From: Bernard Desruisseaux
>>>>>            
>>>> <[email-masked]>
>>>>          
>>>>> Subject: Re: [ietf-calsify] EXRULE Question
>>>>> To: [email-masked]
>>>>> Cc: [email-masked]
>>>>> Date: Wednesday, November 19, 2008, 5:34 PM
>>>>> Adrian Crum wrote:
>>>>>            
>>>>>> While browsing the internet I ran
>>>>>>              
>> across the
>>      
>>>> notes
>>>>          
>>>>> from 2006
>>>>>            
>>>>>> regarding deprecating or removing
>>>>>>              
>> EXRULE and
>>      
>>>> EXDATE
>>>>          
>>>>> from RFC 2445.
>>>>>            
>>>>>> The comments made at the time indicated
>>>>>>              
>> that no
>>      
>>>> one
>>>>          
>>>>> was using it.
>>>>>
>>>>> Only EXRULE was deprecated.  EXDATE can
>>>>>            
>> still be used.
>>      
>>>>>> I'm curious - without those
>>>>>>              
>> properties, how
>>      
>>>> would
>>>>          
>>>>> one express a
>>>>>            
>>>>>> Monday through Friday at 8:00 AM event,
>>>>>>              
>> except on
>>      
>>>> US
>>>>          
>>>>> federal
>>>>>            
>>>>>> holidays?
>>>>>>              
>>>>> Now, you are forced to specify EXDATE one by
>>>>>            
>> one. And
>>      
>>>> of
>>>>          
>>>>> course the number of EXDATE needs to be
>>>>>            
>> finite...
>>      
>>>>> Which is what you'll end up with if you
>>>>>            
>> create
>>      
>>>> your
>>>>          
>>>>> event with pretty much any calendar client
>>>>>            
>> in use
>>      
>>>> today...
>>>>          
>>>>> Cheers,
>>>>> Bernard
>>>>>
>>>>>            
>>>>>> I created an example iCalendar based on
>>>>>>              
>> the
>>      
>>>> original
>>>>          
>>>>> RFC:>
>>>>>            
>>>>>> BEGIN:VCALENDAR
>>>>>> PRODID:-//Apache Open For
>>>>>>              
>> Business//Work Effort
>>      
>>>>> Calendar//EN
>>>>>            
>>>>>> VERSION:2.0
>>>>>> CALSCALE:GREGORIAN
>>>>>> DESCRIPTION:Adrian's Calendar
>>>>>> BEGIN:VEVENT
>>>>>> DTSTAMP:20081112T180905Z
>>>>>> CREATED:20081111T231419Z
>>>>>> LAST-MODIFIED:20081111T232507Z
>>>>>> X-ORG-OFBIZ-WORKEFFORT-ID:10020
>>>>>> SUMMARY:Work Schedule
>>>>>> DESCRIPTION:Work Schedule
>>>>>> ORGANIZER;CN=THE ADMINISTRATOR:
>>>>>> DTSTART:20080101T000043
>>>>>>
>>>>>>              
>> RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
>>      
>>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
>>>>>>
>>>>>>              
>> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
>>      
>>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
>>>>>>
>>>>>>              
>> EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
>>      
>> EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
>>      
>>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
>>>>>>
>>>>>>              
>> EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
>>      
>> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
>>      
>> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
>>      
>> EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
>>      
>>>>>> END:VEVENT
>>>>>> END:VCALENDAR
>>>>>>
>>>>>> I can't find any mention of an
>>>>>>              
>> alternative to
>>      
>>>>> using the EXRULE property, so where would
>>>>>            
>> one go from
>>      
>>>> here?
>>>>          
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>> -- 
>> Less Talk More Gossip
>> http://elbento.com
>> Dan Quayle  - "This President is going to lead us out
>> of this recovery."
>>      
>
>
>

--------------000303030605050206050200--

Date: Thu, 20 Nov 2008 07:58:34 -0800 (PST)
From: Adrian Crum <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] Fw: Re:  Fw: Re: EXRULE Question
Reply-To: [email-masked]

Oops, I did it again.

> > supported and used (interoperably)  and then came to

Date: Thu, 20 Nov 2008 09:07:04 -0600
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question

Hi Adrian,

--On November 19, 2008 9:36:18 PM -0800 Adrian Crum <[email-masked]> 
wrote:

> I disagree that it is hard to implement. The original RFC was clear and
> easy to implement:

Actually it was not clear. Without restating all the discussion we had 
before on this, there are some clear ambiguities in the spec that meant 
interpretation of EXRULE was up to the implementer. Just because you 
implemented it in a way that works for your data does not mean it will work 
the same way in some other product/library.

As an example, the original spec states in the EXRULE definition: "The 
"DTSTART" defines the first instance in the recurrence set.". The (correct) 
reading of this is that an EXRULE will always exclude the first instance in 
any recurrence set. This means, if you really don't want the first instance 
cancelled, you have to adjust the event in some way to create a fake 
"first" instance that is OK to cancel, and then hope the rule does not 
match the second etc but in doing that you may break the behavior of RRULEs 
also present.

That is just one example of ambiguity and lack of clarity. Whilst it might 
have been possible to tighten up the definitions like this, the WG looked 
not only looked at these ambiguities but also at how widely the feature was 
supported and used (interoperably)  and then came to consensus on removal.

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 628208689bc42837d65b316acd4bd2d1
X-Spam-Score-Summary: 2, 0, 0, 47f6250fe99c435d, a0ea87fb493ec7f7, [email-masked], [email-masked]:[email-masked], RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:988:989:1155:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2076:2393:2559:2562:2693:2828:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:4250:5007:6114:7875:8501, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Date: Thu, 20 Nov 2008 13:04:30 -0000
Cc: [email-masked]
Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question

> Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS 
> the original.
>
> That is the point I am trying to make. Calcify isn't just simplifying or 
> clarifying the spec, it is breaking it.

Dropping EXRULE doesn't mean it can never exist, it just means it doesn't 
exist in the base spec.  This makes the spec overall simpler to implement, 
which will increase the number of implementations, and maximize 
interoperability.  I class the two most complex areas of iCalendar to be 
timezone processing and recurrence, and think dropping EXRULE from the 
"base" spec was an excellent idea as it simplifies one of those complex 
areas, while still providing in the "base" spec a way to achieve the same 
functionality - using EXDATE.

Perhaps there's a need for an extension to iCalendar that defines all the 
stuff that got taken out, so implementations like yours can cite support for 
the extended specification, and new impelementations can start with the base 
spec, and then later on consider implementing the extended specifications?

Nigel 

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked], [email-masked]
Date: Thu, 20 Nov 2008 12:12:05 +0100
Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question

Am Donnerstag, 20. November 2008 schrieb Adrian Crum:
> I disagree that it is hard to implement. 

So do I. While KOrganizer has no GUI for creating EXRULE, our libkcal library 
supports an arbitrary number of RRULEs and EXRULEs. KOrganizer of course also 
correctly shows these events.

> The original RFC was clear and 
> easy to implement:
>
> 1. Create a union of all RDATEs and RRULEs
> 2. Create a union of all EXDATEs and EXRULEs
> 3. Create a difference of the two unions

Exactly. Once you have some code creating the recurrence set for one rule, the 
rest is really simple.

Cheers,
Reinhold

> I know this is easy to implement because I've done it. My example works
> with the original RFC. I challenge anyone to prove that it doesn't work
> with the original RFC.
>
> Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS
> the original.
>
> That is the point I am trying to make. Calcify isn't just simplifying or
> clarifying the spec, it is breaking it.
>
> -Adrian
>
> --- On Wed, 11/19/08, Ben Fortuna <[email-masked]> wrote:
> > From: Ben Fortuna <[email-masked]>
> > To: [email-masked]
> > Cc: [email-masked]
> > Date: Wednesday, November 19, 2008, 9:24 PM
> > Adrian,
> >
> > I think you'll find it was removed as it is hard to
> > implement, meaning that
> > many CUAs either didn't support it or had a broken
> > implementation.
> >
> > It should be possible to write some code that converts a
> > recurrence rule to
> > a list of  dates in a specified period (see iCal4j), so
> > from there it
> > shouldn't be hard to convert an EXRULE to a list of
> > EXDATES, and if you
> > choose a large enough period of time it should achieve the
> > same effect
> > (albeit a bit more verbose).
> >
> > Once the new RFC is approved I might investigate supporting
> > automatic
> > conversion of deprecated properties, so things like this
> > should ultimately
> > be transparent.
> >
> > regards,
> > ben
> >
> >
> > On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum
> >
> > > Oops, I meant for this to go to the mailing list.
> > >
> > >
> > > --- On Wed, 11/19/08, Adrian Crum
> >
> > > > Subject: Re: [ietf-calsify] EXRULE Question
> > > > To: "Bernard Desruisseaux"
> >
> > <[email-masked]>
> >
> > > > Date: Wednesday, November 19, 2008, 8:26 PM
> > > > Thank you for the reply!
> > > >
> > > > That is very disappointing. Now I'm forced to
> >
> > define a
> >
> > > > finite amount of discreet dates for exclusions
> >
> > instead of
> >
> > > > specifying a few rules.
> > > >
> > > > I was better off with the original specification.
> > > >
> > > > Other than "no one is using EXRULE" -
> >
> > what is the
> >
> > > > compelling reason to remove it from the RFC? Is
> >
> > everyone in
> >
> > > > calcify that sure that it will never be used?
> > > >
> > > > I thought the objective was to simplify and
> >
> > clarify the
> >
> > > > RFC, not cripple it.
> > > >
> > > > -Adrian
> > > >
> > > >
> > > > --- On Wed, 11/19/08, Bernard Desruisseaux
> > > >
> > > > <[email-masked]> wrote:
> > > > > From: Bernard Desruisseaux
> > > >
> > > > <[email-masked]>
> > > >
> > > > > Subject: Re: [ietf-calsify] EXRULE Question
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]
> > > > > Date: Wednesday, November 19, 2008, 5:34 PM
> > > > >
> > > > > Adrian Crum wrote:
> > > > > > While browsing the internet I ran
> >
> > across the
> >
> > > > notes
> > > >
> > > > > from 2006
> > > > >
> > > > > > regarding deprecating or removing
> >
> > EXRULE and
> >
> > > > EXDATE
> > > >
> > > > > from RFC 2445.
> > > > >
> > > > > > The comments made at the time indicated
> >
> > that no
> >
> > > > one
> > > >
> > > > > was using it.
> > > > >
> > > > > Only EXRULE was deprecated.  EXDATE can
> >
> > still be used.
> >
> > > > > > I'm curious - without those
> >
> > properties, how
> >
> > > > would
> > > >
> > > > > one express a
> > > > >
> > > > > > Monday through Friday at 8:00 AM event,
> >
> > except on
> >
> > > > US
> > > >
> > > > > federal
> > > > >
> > > > > > holidays?
> > > > >
> > > > > Now, you are forced to specify EXDATE one by
> >
> > one. And
> >
> > > > of
> > > >
> > > > > course the number of EXDATE needs to be
> >
> > finite...
> >
> > > > > Which is what you'll end up with if you
> >
> > create
> >
> > > > your
> > > >
> > > > > event with pretty much any calendar client
> >
> > in use
> >
> > > > today...
> > > >
> > > > > Cheers,
> > > > > Bernard
> > > > >
> > > > > > I created an example iCalendar based on
> >
> > the
> >
> > > > original
> > > >
> > > > > RFC: >
> > > > >
> > > > > > BEGIN:VCALENDAR
> > > > > > PRODID:-//Apache Open For
> >
> > Business//Work Effort
> >
> > > > > Calendar//EN
> > > > >
> > > > > > VERSION:2.0
> > > > > > CALSCALE:GREGORIAN
> > > > > > DESCRIPTION:Adrian's Calendar
> > > > > > BEGIN:VEVENT
> > > > > > DTSTAMP:20081112T180905Z
> > > > > > CREATED:20081111T231419Z
> > > > > > LAST-MODIFIED:20081111T232507Z
> > > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > > > > SUMMARY:Work Schedule
> > > > > > DESCRIPTION:Work Schedule
> > > > > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > > > > DTSTART:20080101T000043
> >
> > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> >
> > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> >
> > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> >
> > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> >
> > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> >
> > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> >
> > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> >
> > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> >
> > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> >
> > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> >
> > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> >
> > > > > > END:VEVENT
> > > > > > END:VCALENDAR
> > > > > >
> > > > > > I can't find any mention of an
> >
> > alternative to
> >
> > > > > using the EXRULE property, so where would
> >
> > one go from
> >
> > > > here?
> > > >
> > > > > > -Adrian
> > > >
> > --
> > Less Talk More Gossip
> > http://elbento.com
> > Dan Quayle  - "This President is going to lead us out
> > of this recovery."
>

- -- 

Date: Wed, 19 Nov 2008 21:36:18 -0800 (PST)
From: Adrian Crum <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question
Reply-To: [email-masked]

Ben,

Thanks for the reply.

I disagree that it is hard to implement. The original RFC was clear and easy to implement:

1. Create a union of all RDATEs and RRULEs
2. Create a union of all EXDATEs and EXRULEs
3. Create a difference of the two unions

I know this is easy to implement because I've done it. My example works with the original RFC. I challenge anyone to prove that it doesn't work with the original RFC.

Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS the original.

That is the point I am trying to make. Calcify isn't just simplifying or clarifying the spec, it is breaking it.

-Adrian

--- On Wed, 11/19/08, Ben Fortuna <[email-masked]> wrote:

> From: Ben Fortuna <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: Wednesday, November 19, 2008, 9:24 PM
> Adrian,
> 
> I think you'll find it was removed as it is hard to
> implement, meaning that
> many CUAs either didn't support it or had a broken
> implementation.
> 
> It should be possible to write some code that converts a
> recurrence rule to
> a list of  dates in a specified period (see iCal4j), so
> from there it
> shouldn't be hard to convert an EXRULE to a list of
> EXDATES, and if you
> choose a large enough period of time it should achieve the
> same effect
> (albeit a bit more verbose).
> 
> Once the new RFC is approved I might investigate supporting
> automatic
> conversion of deprecated properties, so things like this
> should ultimately
> be transparent.
> 
> regards,
> ben
> 
> 
> On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum
> > Oops, I meant for this to go to the mailing list.
> >
> >
> > --- On Wed, 11/19/08, Adrian Crum
> > > Subject: Re: [ietf-calsify] EXRULE Question
> > > To: "Bernard Desruisseaux"
> <[email-masked]>
> > > Date: Wednesday, November 19, 2008, 8:26 PM
> > > Thank you for the reply!
> > >
> > > That is very disappointing. Now I'm forced to
> define a
> > > finite amount of discreet dates for exclusions
> instead of
> > > specifying a few rules.
> > >
> > > I was better off with the original specification.
> > >
> > > Other than "no one is using EXRULE" -
> what is the
> > > compelling reason to remove it from the RFC? Is
> everyone in
> > > calcify that sure that it will never be used?
> > >
> > > I thought the objective was to simplify and
> clarify the
> > > RFC, not cripple it.
> > >
> > > -Adrian
> > >
> > >
> > > --- On Wed, 11/19/08, Bernard Desruisseaux
> > > <[email-masked]> wrote:
> > >
> > > > From: Bernard Desruisseaux
> > > <[email-masked]>
> > > > Subject: Re: [ietf-calsify] EXRULE Question
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Date: Wednesday, November 19, 2008, 5:34 PM
> > > > Adrian Crum wrote:
> > > > > While browsing the internet I ran
> across the
> > > notes
> > > > from 2006
> > > > > regarding deprecating or removing
> EXRULE and
> > > EXDATE
> > > > from RFC 2445.
> > > > > The comments made at the time indicated
> that no
> > > one
> > > > was using it.
> > > >
> > > > Only EXRULE was deprecated.  EXDATE can
> still be used.
> > > >
> > > > >
> > > > > I'm curious - without those
> properties, how
> > > would
> > > > one express a
> > > > > Monday through Friday at 8:00 AM event,
> except on
> > > US
> > > > federal
> > > > > holidays?
> > > >
> > > > Now, you are forced to specify EXDATE one by
> one. And
> > > of
> > > > course the number of EXDATE needs to be
> finite...
> > > >
> > > > Which is what you'll end up with if you
> create
> > > your
> > > > event with pretty much any calendar client
> in use
> > > today...
> > > >
> > > > Cheers,
> > > > Bernard
> > > >
> > > > >
> > > > > I created an example iCalendar based on
> the
> > > original
> > > > RFC: >
> > > > > BEGIN:VCALENDAR
> > > > > PRODID:-//Apache Open For
> Business//Work Effort
> > > > Calendar//EN
> > > > > VERSION:2.0
> > > > > CALSCALE:GREGORIAN
> > > > > DESCRIPTION:Adrian's Calendar
> > > > > BEGIN:VEVENT
> > > > > DTSTAMP:20081112T180905Z
> > > > > CREATED:20081111T231419Z
> > > > > LAST-MODIFIED:20081111T232507Z
> > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > > > SUMMARY:Work Schedule
> > > > > DESCRIPTION:Work Schedule
> > > > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > > > DTSTART:20080101T000043
> > > > >
> RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> > > > >
> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> > > > >
> EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> > > > >
> EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> > > > >
> EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> > > > >
> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> > > > >
> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> > > > >
> EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> > > > > END:VEVENT
> > > > > END:VCALENDAR
> > > > >
> > > > > I can't find any mention of an
> alternative to
> > > > using the EXRULE property, so where would
> one go from
> > > here?
> > > > >
> > > > > -Adrian
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> -- 
> Less Talk More Gossip
> http://elbento.com
> Dan Quayle  - "This President is going to lead us out
> of this recovery."

Date: Thu, 20 Nov 2008 16:26:33 +1100
From: "Ben Fortuna" <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question

------=_Part_2498_12805163.1227158793860
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Sorry, that should read:

"Once the new RFC is approved I might investigate supporting automatic
conversion of deprecated properties *in iCal4j*, so things like this should
ultimately be transparent."

On Thu, Nov 20, 2008 at 4:24 PM, Ben Fortuna
<[email-masked]>wrote:

> Adrian,
>
> I think you'll find it was removed as it is hard to implement, meaning that
> many CUAs either didn't support it or had a broken implementation.
>
> It should be possible to write some code that converts a recurrence rule to
> a list of  dates in a specified period (see iCal4j), so from there it
> shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you
> choose a large enough period of time it should achieve the same effect
> (albeit a bit more verbose).
>
> Once the new RFC is approved I might investigate supporting automatic
> conversion of deprecated properties, so things like this should ultimately
> be transparent.
>
> regards,
> ben
>
>
>
> On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <[email-masked]>wrote:
>
>> Oops, I meant for this to go to the mailing list.
>>
>>
>> --- On Wed, 11/19/08, Adrian Crum <[email-masked]> wrote:
>>
>> > Subject: Re: [ietf-calsify] EXRULE Question
>> > To: "Bernard Desruisseaux" <[email-masked]>
>> > Date: Wednesday, November 19, 2008, 8:26 PM
>> > Thank you for the reply!
>> >
>> > That is very disappointing. Now I'm forced to define a
>> > finite amount of discreet dates for exclusions instead of
>> > specifying a few rules.
>> >
>> > I was better off with the original specification.
>> >
>> > Other than "no one is using EXRULE" - what is the
>> > compelling reason to remove it from the RFC? Is everyone in
>> > calcify that sure that it will never be used?
>> >
>> > I thought the objective was to simplify and clarify the
>> > RFC, not cripple it.
>> >
>> > -Adrian
>> >
>> >
>> > --- On Wed, 11/19/08, Bernard Desruisseaux
>> > <[email-masked]> wrote:
>> >
>> > > From: Bernard Desruisseaux
>> > <[email-masked]>
>> > > Subject: Re: [ietf-calsify] EXRULE Question
>> > > To: [email-masked]
>> > > Cc: [email-masked]
>> > > Date: Wednesday, November 19, 2008, 5:34 PM
>> > > Adrian Crum wrote:
>> > > > While browsing the internet I ran across the
>> > notes
>> > > from 2006
>> > > > regarding deprecating or removing EXRULE and
>> > EXDATE
>> > > from RFC 2445.
>> > > > The comments made at the time indicated that no
>> > one
>> > > was using it.
>> > >
>> > > Only EXRULE was deprecated.  EXDATE can still be used.
>> > >
>> > > >
>> > > > I'm curious - without those properties, how
>> > would
>> > > one express a
>> > > > Monday through Friday at 8:00 AM event, except on
>> > US
>> > > federal
>> > > > holidays?
>> > >
>> > > Now, you are forced to specify EXDATE one by one. And
>> > of
>> > > course the number of EXDATE needs to be finite...
>> > >
>> > > Which is what you'll end up with if you create
>> > your
>> > > event with pretty much any calendar client in use
>> > today...
>> > >
>> > > Cheers,
>> > > Bernard
>> > >
>> > > >
>> > > > I created an example iCalendar based on the
>> > original
>> > > RFC: >
>> > > > BEGIN:VCALENDAR
>> > > > PRODID:-//Apache Open For Business//Work Effort
>> > > Calendar//EN
>> > > > VERSION:2.0
>> > > > CALSCALE:GREGORIAN
>> > > > DESCRIPTION:Adrian's Calendar
>> > > > BEGIN:VEVENT
>> > > > DTSTAMP:20081112T180905Z
>> > > > CREATED:20081111T231419Z
>> > > > LAST-MODIFIED:20081111T232507Z
>> > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
>> > > > SUMMARY:Work Schedule
>> > > > DESCRIPTION:Work Schedule
>> > > > ORGANIZER;CN=THE ADMINISTRATOR:
>> > > > DTSTART:20080101T000043
>> > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
>> > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
>> > > > END:VEVENT
>> > > > END:VCALENDAR
>> > > >
>> > > > I can't find any mention of an alternative to
>> > > using the EXRULE property, so where would one go from
>> > here?
>> > > >
>> > > > -Adrian
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
> --
> Dan Quayle  - "This President is going to lead us out of this recovery."

-- 
Fred Allen  - "An associate producer is the only guy in Hollywood who will
associate with a producer."

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

Sorry, that should read:<br><br>&quot;Once the new RFC is approved I might investigate supporting automatic
conversion of deprecated properties <b>in iCal4j</b>, so things like this should
ultimately be transparent.&quot;<br><br><br><div class="gmail_quote">On Thu, Nov 20, 2008 at 4:24 PM, Ben Fortuna <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Adrian,<br><br>I think you&#39;ll find it was removed as it is hard to implement, meaning that many CUAs either didn&#39;t support it or had a broken implementation.<br>
<br>It should be possible to write some code that converts a recurrence rule to a list of&nbsp; dates in a specified period (see iCal4j), so from there it shouldn&#39;t be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose).<br>

<br>Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent.<br><br>regards,<br>ben<div><div></div><div class="Wj3C7c">
<br><br><br><div class="gmail_quote">
On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Oops, I meant for this to go to the mailing list.<br>
<br>
<br>
--- On Wed, 11/19/08, Adrian Crum &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
<br>
&gt; From: Adrian Crum &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;<br>
&gt; Subject: Re: [ietf-calsify] EXRULE Question<br>
&gt; To: &quot;Bernard Desruisseaux&quot; &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;<br>
&gt; Date: Wednesday, November 19, 2008, 8:26 PM<br>
&gt; Thank you for the reply!<br>
&gt;<br>
&gt; That is very disappointing. Now I&#39;m forced to define a<br>
&gt; finite amount of discreet dates for exclusions instead of<br>
&gt; specifying a few rules.<br>
&gt;<br>
&gt; I was better off with the original specification.<br>
&gt;<br>
&gt; Other than &quot;no one is using EXRULE&quot; - what is the<br>
&gt; compelling reason to remove it from the RFC? Is everyone in<br>
&gt; calcify that sure that it will never be used?<br>
&gt;<br>
&gt; I thought the objective was to simplify and clarify the<br>
&gt; RFC, not cripple it.<br>
&gt;<br>
&gt; -Adrian<br>
&gt;<br>
&gt;<br>
&gt; --- On Wed, 11/19/08, Bernard Desruisseaux<br>
&gt; &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; From: Bernard Desruisseaux<br>
&gt; &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;<br>
&gt; &gt; Subject: Re: [ietf-calsify] EXRULE Question<br>
&gt; &gt; To: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt; &gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt; &gt; Date: Wednesday, November 19, 2008, 5:34 PM<br>
<div><div></div><div>&gt; &gt; Adrian Crum wrote:<br>
&gt; &gt; &gt; While browsing the internet I ran across the<br>
&gt; notes<br>
&gt; &gt; from 2006<br>
&gt; &gt; &gt; regarding deprecating or removing EXRULE and<br>
&gt; EXDATE<br>
&gt; &gt; from RFC 2445.<br>
&gt; &gt; &gt; The comments made at the time indicated that no<br>
&gt; one<br>
&gt; &gt; was using it.<br>
&gt; &gt;<br>
&gt; &gt; Only EXRULE was deprecated. &nbsp;EXDATE can still be used.<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m curious - without those properties, how<br>
&gt; would<br>
&gt; &gt; one express a<br>
&gt; &gt; &gt; Monday through Friday at 8:00 AM event, except on<br>
&gt; US<br>
&gt; &gt; federal<br>
&gt; &gt; &gt; holidays?<br>
&gt; &gt;<br>
&gt; &gt; Now, you are forced to specify EXDATE one by one. And<br>
&gt; of<br>
&gt; &gt; course the number of EXDATE needs to be finite...<br>
&gt; &gt;<br>
&gt; &gt; Which is what you&#39;ll end up with if you create<br>
&gt; your<br>
&gt; &gt; event with pretty much any calendar client in use<br>
&gt; today...<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt; Bernard<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I created an example iCalendar based on the<br>
&gt; original<br>
&gt; &gt; RFC: &gt;<br>
&gt; &gt; &gt; BEGIN:VCALENDAR<br>
&gt; &gt; &gt; PRODID:-//Apache Open For Business//Work Effort<br>
&gt; &gt; Calendar//EN<br>
&gt; &gt; &gt; VERSION:2.0<br>
&gt; &gt; &gt; CALSCALE:GREGORIAN<br>
&gt; &gt; &gt; DESCRIPTION:Adrian&#39;s Calendar<br>
&gt; &gt; &gt; BEGIN:VEVENT<br>
&gt; &gt; &gt; DTSTAMP:20081112T180905Z<br>
&gt; &gt; &gt; CREATED:20081111T231419Z<br>
&gt; &gt; &gt; LAST-MODIFIED:20081111T232507Z<br>
&gt; &gt; &gt; X-ORG-OFBIZ-WORKEFFORT-ID:10020<br>
&gt; &gt; &gt; SUMMARY:Work Schedule<br>
&gt; &gt; &gt; DESCRIPTION:Work Schedule<br>
&gt; &gt; &gt; ORGANIZER;CN=THE ADMINISTRATOR:<br>
&gt; &gt; &gt; DTSTART:20080101T000043<br>
&gt; &gt; &gt; RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25<br>
&gt; &gt; &gt; END:VEVENT<br>
&gt; &gt; &gt; END:VCALENDAR<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I can&#39;t find any mention of an alternative to<br>
&gt; &gt; using the EXRULE property, so where would one go from<br>
&gt; here?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -Adrian<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; _______________________________________________<br>
&gt; &gt; &gt; ietf-calsify mailing list<br>
&gt; &gt; &gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; <a href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify" target="_blank">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a><br>
&gt; &gt; &gt;<br>
<br>
<br>
<br>
_______________________________________________<br>
ietf-calsify mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify" target="_blank">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a><br>
</div></div></blockquote></div><br><br clear="all"></div></div><font color="#888888">--<br>Dan Quayle &nbsp;- &quot;This President is going to lead us out of this recovery.&quot;
</font></blockquote></div><br><br clear="all"><br>-- <br>Fred Allen &nbsp;- &quot;An associate producer is the only guy in Hollywood who will associate with a producer.&quot;

------=_Part_2498_12805163.1227158793860--

Date: Thu, 20 Nov 2008 16:24:18 +1100
From: "Ben Fortuna" <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question

------=_Part_2456_5317785.1227158658574
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Adrian,

I think you'll find it was removed as it is hard to implement, meaning that
many CUAs either didn't support it or had a broken implementation.

It should be possible to write some code that converts a recurrence rule to
a list of  dates in a specified period (see iCal4j), so from there it
shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you
choose a large enough period of time it should achieve the same effect
(albeit a bit more verbose).

Once the new RFC is approved I might investigate supporting automatic
conversion of deprecated properties, so things like this should ultimately
be transparent.

regards,
ben

On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <[email-masked]> wrote:

> Oops, I meant for this to go to the mailing list.
>
>
> --- On Wed, 11/19/08, Adrian Crum <[email-masked]> wrote:
>
> > Subject: Re: [ietf-calsify] EXRULE Question
> > To: "Bernard Desruisseaux" <[email-masked]>
> > Date: Wednesday, November 19, 2008, 8:26 PM
> > Thank you for the reply!
> >
> > That is very disappointing. Now I'm forced to define a
> > finite amount of discreet dates for exclusions instead of
> > specifying a few rules.
> >
> > I was better off with the original specification.
> >
> > Other than "no one is using EXRULE" - what is the
> > compelling reason to remove it from the RFC? Is everyone in
> > calcify that sure that it will never be used?
> >
> > I thought the objective was to simplify and clarify the
> > RFC, not cripple it.
> >
> > -Adrian
> >
> >
> > --- On Wed, 11/19/08, Bernard Desruisseaux
> > <[email-masked]> wrote:
> >
> > > From: Bernard Desruisseaux
> > <[email-masked]>
> > > Subject: Re: [ietf-calsify] EXRULE Question
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Date: Wednesday, November 19, 2008, 5:34 PM
> > > Adrian Crum wrote:
> > > > While browsing the internet I ran across the
> > notes
> > > from 2006
> > > > regarding deprecating or removing EXRULE and
> > EXDATE
> > > from RFC 2445.
> > > > The comments made at the time indicated that no
> > one
> > > was using it.
> > >
> > > Only EXRULE was deprecated.  EXDATE can still be used.
> > >
> > > >
> > > > I'm curious - without those properties, how
> > would
> > > one express a
> > > > Monday through Friday at 8:00 AM event, except on
> > US
> > > federal
> > > > holidays?
> > >
> > > Now, you are forced to specify EXDATE one by one. And
> > of
> > > course the number of EXDATE needs to be finite...
> > >
> > > Which is what you'll end up with if you create
> > your
> > > event with pretty much any calendar client in use
> > today...
> > >
> > > Cheers,
> > > Bernard
> > >
> > > >
> > > > I created an example iCalendar based on the
> > original
> > > RFC: >
> > > > BEGIN:VCALENDAR
> > > > PRODID:-//Apache Open For Business//Work Effort
> > > Calendar//EN
> > > > VERSION:2.0
> > > > CALSCALE:GREGORIAN
> > > > DESCRIPTION:Adrian's Calendar
> > > > BEGIN:VEVENT
> > > > DTSTAMP:20081112T180905Z
> > > > CREATED:20081111T231419Z
> > > > LAST-MODIFIED:20081111T232507Z
> > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > > SUMMARY:Work Schedule
> > > > DESCRIPTION:Work Schedule
> > > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > > DTSTART:20080101T000043
> > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> > > > END:VEVENT
> > > > END:VCALENDAR
> > > >
> > > > I can't find any mention of an alternative to
> > > using the EXRULE property, so where would one go from
> > here?
> > > >
> > > > -Adrian
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >

-- 
Less Talk More Gossip
http://elbento.com

Dan Quayle  - "This President is going to lead us out of this recovery."

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

Adrian,<br><br>I think you&#39;ll find it was removed as it is hard to implement, meaning that many CUAs either didn&#39;t support it or had a broken implementation.<br><br>It should be possible to write some code that converts a recurrence rule to a list of&nbsp; dates in a specified period (see iCal4j), so from there it shouldn&#39;t be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose).<br>
<br>Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent.<br><br>regards,<br>ben<br><br><br><div class="gmail_quote">
On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Oops, I meant for this to go to the mailing list.<br>
<br>
<br>
--- On Wed, 11/19/08, Adrian Crum &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
&gt; From: Adrian Crum &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt; Subject: Re: [ietf-calsify] EXRULE Question<br>
&gt; To: &quot;Bernard Desruisseaux&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt; Date: Wednesday, November 19, 2008, 8:26 PM<br>
&gt; Thank you for the reply!<br>
&gt;<br>
&gt; That is very disappointing. Now I&#39;m forced to define a<br>
&gt; finite amount of discreet dates for exclusions instead of<br>
&gt; specifying a few rules.<br>
&gt;<br>
&gt; I was better off with the original specification.<br>
&gt;<br>
&gt; Other than &quot;no one is using EXRULE&quot; - what is the<br>
&gt; compelling reason to remove it from the RFC? Is everyone in<br>
&gt; calcify that sure that it will never be used?<br>
&gt;<br>
&gt; I thought the objective was to simplify and clarify the<br>
&gt; RFC, not cripple it.<br>
&gt;<br>
&gt; -Adrian<br>
&gt;<br>
&gt;<br>
&gt; --- On Wed, 11/19/08, Bernard Desruisseaux<br>
&gt; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; From: Bernard Desruisseaux<br>
&gt; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt; &gt; Subject: Re: [ietf-calsify] EXRULE Question<br>
&gt; &gt; To: <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt; &gt; Cc: <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt; &gt; Date: Wednesday, November 19, 2008, 5:34 PM<br>
<div><div></div><div class="Wj3C7c">&gt; &gt; Adrian Crum wrote:<br>
&gt; &gt; &gt; While browsing the internet I ran across the<br>
&gt; notes<br>
&gt; &gt; from 2006<br>
&gt; &gt; &gt; regarding deprecating or removing EXRULE and<br>
&gt; EXDATE<br>
&gt; &gt; from RFC 2445.<br>
&gt; &gt; &gt; The comments made at the time indicated that no<br>
&gt; one<br>
&gt; &gt; was using it.<br>
&gt; &gt;<br>
&gt; &gt; Only EXRULE was deprecated. &nbsp;EXDATE can still be used.<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m curious - without those properties, how<br>
&gt; would<br>
&gt; &gt; one express a<br>
&gt; &gt; &gt; Monday through Friday at 8:00 AM event, except on<br>
&gt; US<br>
&gt; &gt; federal<br>
&gt; &gt; &gt; holidays?<br>
&gt; &gt;<br>
&gt; &gt; Now, you are forced to specify EXDATE one by one. And<br>
&gt; of<br>
&gt; &gt; course the number of EXDATE needs to be finite...<br>
&gt; &gt;<br>
&gt; &gt; Which is what you&#39;ll end up with if you create<br>
&gt; your<br>
&gt; &gt; event with pretty much any calendar client in use<br>
&gt; today...<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt; Bernard<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I created an example iCalendar based on the<br>
&gt; original<br>
&gt; &gt; RFC: &gt;<br>
&gt; &gt; &gt; BEGIN:VCALENDAR<br>
&gt; &gt; &gt; PRODID:-//Apache Open For Business//Work Effort<br>
&gt; &gt; Calendar//EN<br>
&gt; &gt; &gt; VERSION:2.0<br>
&gt; &gt; &gt; CALSCALE:GREGORIAN<br>
&gt; &gt; &gt; DESCRIPTION:Adrian&#39;s Calendar<br>
&gt; &gt; &gt; BEGIN:VEVENT<br>
&gt; &gt; &gt; DTSTAMP:20081112T180905Z<br>
&gt; &gt; &gt; CREATED:20081111T231419Z<br>
&gt; &gt; &gt; LAST-MODIFIED:20081111T232507Z<br>
&gt; &gt; &gt; X-ORG-OFBIZ-WORKEFFORT-ID:10020<br>
&gt; &gt; &gt; SUMMARY:Work Schedule<br>
&gt; &gt; &gt; DESCRIPTION:Work Schedule<br>
&gt; &gt; &gt; ORGANIZER;CN=THE ADMINISTRATOR:<br>
&gt; &gt; &gt; DTSTART:20080101T000043<br>
&gt; &gt; &gt; RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH<br>
&gt; &gt; &gt; EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25<br>
&gt; &gt; &gt; END:VEVENT<br>
&gt; &gt; &gt; END:VCALENDAR<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I can&#39;t find any mention of an alternative to<br>
&gt; &gt; using the EXRULE property, so where would one go from<br>
&gt; here?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -Adrian<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; _______________________________________________<br>
&gt; &gt; &gt; ietf-calsify mailing list<br>
&gt; &gt; &gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; <a href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify" target="_blank">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a><br>
&gt; &gt; &gt;<br>
<br>
<br>
<br>
_______________________________________________<br>
ietf-calsify mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify" target="_blank">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Less Talk More Gossip<br><a href="http://elbento.com">http://elbento.com</a><br><br>Dan Quayle &nbsp;- &quot;This President is going to lead us out of this recovery.&quot;

------=_Part_2456_5317785.1227158658574--

Date: Wed, 19 Nov 2008 20:33:06 -0800 (PST)
From: Adrian Crum <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] Fw: Re:  EXRULE Question
Reply-To: [email-masked]

Oops, I meant for this to go to the mailing list.

--- On Wed, 11/19/08, Adrian Crum <[email-masked]> wrote:

> Subject: Re: [ietf-calsify] EXRULE Question
> To: "Bernard Desruisseaux" <[email-masked]>
> Date: Wednesday, November 19, 2008, 8:26 PM
> Thank you for the reply!
> 
> That is very disappointing. Now I'm forced to define a
> finite amount of discreet dates for exclusions instead of
> specifying a few rules.
> 
> I was better off with the original specification.
> 
> Other than "no one is using EXRULE" - what is the
> compelling reason to remove it from the RFC? Is everyone in
> calcify that sure that it will never be used?
> 
> I thought the objective was to simplify and clarify the
> RFC, not cripple it.
> 
> -Adrian
> 
> 
> --- On Wed, 11/19/08, Bernard Desruisseaux
> <[email-masked]> wrote:
> 
> > From: Bernard Desruisseaux
> <[email-masked]>
> > Subject: Re: [ietf-calsify] EXRULE Question
> > To: [email-masked]
> > Cc: [email-masked]
> > Date: Wednesday, November 19, 2008, 5:34 PM
> > Adrian Crum wrote:
> > > While browsing the internet I ran across the
> notes
> > from 2006
> > > regarding deprecating or removing EXRULE and
> EXDATE
> > from RFC 2445.
> > > The comments made at the time indicated that no
> one
> > was using it.
> > 
> > Only EXRULE was deprecated.  EXDATE can still be used.
> > 
> > > 
> > > I'm curious - without those properties, how
> would
> > one express a
> > > Monday through Friday at 8:00 AM event, except on
> US
> > federal
> > > holidays?
> > 
> > Now, you are forced to specify EXDATE one by one. And
> of
> > course the number of EXDATE needs to be finite...
> > 
> > Which is what you'll end up with if you create
> your
> > event with pretty much any calendar client in use
> today...
> > 
> > Cheers,
> > Bernard
> > 
> > > 
> > > I created an example iCalendar based on the
> original
> > RFC: >
> > > BEGIN:VCALENDAR
> > > PRODID:-//Apache Open For Business//Work Effort
> > Calendar//EN
> > > VERSION:2.0
> > > CALSCALE:GREGORIAN
> > > DESCRIPTION:Adrian's Calendar
> > > BEGIN:VEVENT
> > > DTSTAMP:20081112T180905Z
> > > CREATED:20081111T231419Z
> > > LAST-MODIFIED:20081111T232507Z
> > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > SUMMARY:Work Schedule
> > > DESCRIPTION:Work Schedule
> > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > DTSTART:20080101T000043
> > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> > > END:VEVENT
> > > END:VCALENDAR
> > > 
> > > I can't find any mention of an alternative to
> > using the EXRULE property, so where would one go from
> here?
> > > 
> > > -Adrian
> > > 
> > > 
> > > 
> > > 
> > > 
> > >      

Date: Wed, 19 Nov 2008 20:34:04 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-calsify] EXRULE Question

Adrian Crum wrote:
> While browsing the internet I ran across the notes from 2006
> regarding deprecating or removing EXRULE and EXDATE from RFC 2445.
> The comments made at the time indicated that no one was using it.

Only EXRULE was deprecated.  EXDATE can still be used.

> 
> I'm curious - without those properties, how would one express a
> Monday through Friday at 8:00 AM event, except on US federal
> holidays?

Now, you are forced to specify EXDATE one by one. And of course the 
number of EXDATE needs to be finite...

Which is what you'll end up with if you create your event with pretty 
much any calendar client in use today...

Cheers,
Bernard

> 
> I created an example iCalendar based on the original RFC: >
> BEGIN:VCALENDAR
> PRODID:-//Apache Open For Business//Work Effort Calendar//EN
> VERSION:2.0
> CALSCALE:GREGORIAN
> DESCRIPTION:Adrian's Calendar
> BEGIN:VEVENT
> DTSTAMP:20081112T180905Z
> CREATED:20081111T231419Z
> LAST-MODIFIED:20081111T232507Z
> X-ORG-OFBIZ-WORKEFFORT-ID:10020
> SUMMARY:Work Schedule
> DESCRIPTION:Work Schedule
> ORGANIZER;CN=THE ADMINISTRATOR:
> DTSTART:20080101T000043
> RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> END:VEVENT
> END:VCALENDAR
> 
> I can't find any mention of an alternative to using the EXRULE property, so where would one go from here?
> 
> -Adrian
> 
> 
> 
> 
> 
>       

Date: Wed, 19 Nov 2008 20:15:13 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Ken Shoemake <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09

Hi Ken,

I finally submitted the XML version of the draft to the IETF.
It is now available here:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-09.xml

It is also accessible from the "Calsify Status Pages" here:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/

Cheers,
Bernard

Ken Shoemake wrote:
> Trying this reply again also.
> 
> Bernard Desruisseaux wrote:
>  > I've been using Julian Reschke's "extract-artwork.xslt" 
> transformation against the XML version of the draft to extract ABNF from 
> the draft. See:
>  >
>  > 
> http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork 
> 
> 
> Will the XML version be available when the standard is approved? If so, 
> then extraction from that would indeed seem easier and more reliable 
> than using a text-based tool like aex. Unfortunately, I cannot seem to 
> find a copy of the draft in XML format in the obvious place,
>    <http://www.ietf.org/internet-drafts/>
> Where should I be looking?
> 
>   -- Ken
> 

Date: Wed, 19 Nov 2008 12:41:44 -0800 (PST)
From: Adrian Crum <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] EXRULE Question
Reply-To: [email-masked]

While browsing the internet I ran across the notes from 2006 regarding deprecating or removing EXRULE and EXDATE from RFC 2445. The comments made at the time indicated that no one was using it.

I'm curious - without those properties, how would one express a Monday through Friday at 8:00 AM event, except on US federal holidays?

I created an example iCalendar based on the original RFC:

BEGIN:VCALENDAR
PRODID:-//Apache Open For Business//Work Effort Calendar//EN
VERSION:2.0
CALSCALE:GREGORIAN
DESCRIPTION:Adrian's Calendar
BEGIN:VEVENT
DTSTAMP:20081112T180905Z
CREATED:20081111T231419Z
LAST-MODIFIED:20081111T232507Z
X-ORG-OFBIZ-WORKEFFORT-ID:10020
SUMMARY:Work Schedule
DESCRIPTION:Work Schedule
ORGANIZER;CN=THE ADMINISTRATOR:
DTSTART:20080101T000043
RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
END:VEVENT
END:VCALENDAR

I can't find any mention of an alternative to using the EXRULE property, so where would one go from here?

-Adrian

Date: Tue, 18 Nov 2008 05:38:39 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09

Nigel Swinson wrote:
> But then immediately proceeding that you've included two 20+ line 
> sections supposedly where one is different to the other.  Sifting 
> through what you have changed is extremely difficult.

Before I gave the change I stated that it consisted of moving the note 
on notes and including a new note. Perhaps it was confusing because I 
gave the new text first, and did not label which was old and which new.

Still, I assumed that Bernard, who had asked "[W]hat change or 
clarifying text would you like to see added in the draft?", would have 
little difficulty with my reply.

An ancient but still useful standard for changes is much as you suggest, 
however in this case it would obscure the fact that a paragraph (the 
note on notes) was moved.

Moving that paragraph makes logical sense for two reasons:
  1. It should precede the use of the indented note convention for my 
new remark.
  2. It seems natural in the flow of exposition for it to follow the 
paragraph on formal and informal notation.

Again, the only substantive change proposed is to add one new sentence.

I am satisfied that such a note will suffice, and there is precedent. 
Among the ABNF given in rfc2445bis-09 is this:
   eventc     = "BEGIN" ":" "VEVENT" CRLF
                eventprop *alarmc
                "END" ":" "VEVENT" CRLF
Section 2.3 of [RFC5234] says that "ABNF strings are case insensitive", 
so implicitly we know that "begin:vevent" or "Begin:vEvent" are to be 
accepted along with "BEGIN:VEVENT". Yet rfc2445bis-09 finds it prudent 
to explicitly say "All names of properties, property parameters, 
enumerated property values and property parameter values are 
case-insensitive."

Adding the comment about white space is also prudent, as I hope we agree.

  -- Ken Shoemake

Date: Mon, 17 Nov 2008 10:55:09 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Ken Shoemake <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-calsify] rfc2445bis-09 nit

Hi Ken,

The General Area Review Team (Gen-ART) also spotted this typo during 
their review.  It's fixed now.

Thanks,
Bernard

Ken Shoemake wrote:
> In section 3.7.3, Product Identifier, the Description says "This 
> property SHOULD not"; its capitalization needs to be changed to "This 
> property SHOULD NOT", according to the nit finder.
> 
> Also there is some complaint about boilerplate which may deserve attention.
> 
>   -- Ken

Date: Sat, 15 Nov 2008 03:33:06 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09

Trying this reply again also.

Bernard Desruisseaux wrote:
 > I've been using Julian Reschke's "extract-artwork.xslt" 
transformation against the XML version of the draft to extract ABNF from 
the draft. See:
http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork 

Will the XML version be available when the standard is approved? If so, 
then extraction from that would indeed seem easier and more reliable 
than using a text-based tool like aex. Unfortunately, I cannot seem to 
find a copy of the draft in XML format in the obvious place,
   <http://www.ietf.org/internet-drafts/>
Where should I be looking?

  -- Ken

Date: Sat, 15 Nov 2008 03:32:01 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09

Trying reply again.

Bernard Desruisseaux wrote:
 > Given that we are already making reference to RFC5234, and that our 
intent is NOT to permit linear white space around delimiters or string 
segments, what change or clarifying text would you like to see added in 
the draft?
In section 2, Basic Grammar and Conventions, I would revise the text to 
include a new note, and move the note on notes, as follows.
   ----------
    This memo makes use of both a descriptive prose and a more formal
    notation for defining the calendaring and scheduling format.

       Note: All indented editorial notes, such as this one, are intended
       to provide the reader with additional information.  The
       information is not essential to the building of an implementation
       conformant with this memo.  The information is provided to
       highlight a particular feature or characteristic of the memo.

    The notation used in this memo is the ABNF notation of [RFC5234].
    Readers intending on implementing the format defined in this memo
    should be familiar with this notation in order to properly interpret
    the specifications of this memo.

       Note: Spaces and horizontal tabs (formally, linear white space)
       are only allowed where explicitly stated in the notation, never
       implicitly; see section 3.1 of [RFC5234].

    All numeric values used in this memo are given in decimal notation.

    All names of properties, property parameters, enumerated property
    values and property parameter values are case-insensitive.  However,
    all other property values are case-sensitive, unless otherwise
    stated.
   ----------
    This memo makes use of both a descriptive prose and a more formal
    notation for defining the calendaring and scheduling format.

    The notation used in this memo is the ABNF notation of [RFC5234].
    Readers intending on implementing the format defined in this memo
    should be familiar with this notation in order to properly interpret
    the specifications of this memo.

    All numeric values used in this memo are given in decimal notation.

    All names of properties, property parameters, enumerated property
    values and property parameter values are case-insensitive.  However,
    all other property values are case-sensitive, unless otherwise
    stated.

       Note: All indented editorial notes, such as this one, are intended
       to provide the reader with additional information.  The
       information is not essential to the building of an implementation
       conformant with this memo.  The information is provided to
       highlight a particular feature or characteristic of the memo.
   ----------

The single new sentence provides two benefits.
  1. It states the intent here, rather than forcing the reader to sift 
through and interpret a large secondary document.
  2. It shields this document from historical interpretations of ABNF so 
there can be no question of accidental intent.

Although files will be read by programs more than humans, text formats 
frequently admit flexible use of linear white space. When going against 
convention it is best to alert readers explicitly.

  -- Ken Shoemake

Date: Sat, 15 Nov 2008 02:48:17 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] [Fwd: Re:  ABNF intent in rfc2445bis-09]

This is a multi-part message in MIME format.
--------------090601050806040306020607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

--------------090601050806040306020607
Content-Type: message/rfc822;
 name="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml"

Date: Fri, 14 Nov 2008 17:26:34 -0500
From: Ken Shoemake <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09

Bernard Desruisseaux wrote:
> I've been using Julian Reschke's "extract-artwork.xslt" transformation 
> against the XML version of the draft to extract ABNF from the draft. See:
> 
> http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork 

Will the XML version be available when the standard is approved? If so, 
then extraction from that would indeed seem easier and more reliable 
than using a text-based tool like aex. Unfortunately, I cannot seem to 
find a copy of the draft in XML format in the obvious place,
   <http://www.ietf.org/internet-drafts/>
Where should I be looking?

  -- Ken

--------------090601050806040306020607--

Date: Sat, 15 Nov 2008 02:47:44 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] [Fwd: Re:  ABNF intent in rfc2445bis-09]

This is a multi-part message in MIME format.
--------------020208010108070901030609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

--------------020208010108070901030609
Content-Type: message/rfc822;
 name="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml"

Date: Fri, 14 Nov 2008 16:10:17 -0500
From: Ken Shoemake <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09

Bernard Desruisseaux wrote:
> Given that we are already making reference to RFC5234, and that our 
> intent is NOT to permit linear white space around delimiters or string 
> segments, what change or clarifying text would you like to see added in 
> the draft?
In section 2, Basic Grammar and Conventions, I would revise the text to 
include a new note, and move the note on notes, as follows.
   ----------
    This memo makes use of both a descriptive prose and a more formal
    notation for defining the calendaring and scheduling format.

       Note: All indented editorial notes, such as this one, are intended
       to provide the reader with additional information.  The
       information is not essential to the building of an implementation
       conformant with this memo.  The information is provided to
       highlight a particular feature or characteristic of the memo.

    The notation used in this memo is the ABNF notation of [RFC5234].
    Readers intending on implementing the format defined in this memo
    should be familiar with this notation in order to properly interpret
    the specifications of this memo.

       Note: Spaces and horizontal tabs (formally, linear white space)
       are only allowed where explicitly stated in the notation, never
       implicitly; see section 3.1 of [RFC5234].

    All numeric values used in this memo are given in decimal notation.

    All names of properties, property parameters, enumerated property
    values and property parameter values are case-insensitive.  However,
    all other property values are case-sensitive, unless otherwise
    stated.
   ----------
    This memo makes use of both a descriptive prose and a more formal
    notation for defining the calendaring and scheduling format.

    The notation used in this memo is the ABNF notation of [RFC5234].
    Readers intending on implementing the format defined in this memo
    should be familiar with this notation in order to properly interpret
    the specifications of this memo.

    All numeric values used in this memo are given in decimal notation.

    All names of properties, property parameters, enumerated property
    values and property parameter values are case-insensitive.  However,
    all other property values are case-sensitive, unless otherwise
    stated.

       Note: All indented editorial notes, such as this one, are intended
       to provide the reader with additional information.  The
       information is not essential to the building of an implementation
       conformant with this memo.  The information is provided to
       highlight a particular feature or characteristic of the memo.
   ----------

The single new sentence provides two benefits.
  1. It states the intent here, rather than forcing the reader to sift 
through and interpret a large secondary document.
  2. It shields this document from historical interpretations of ABNF so 
there can be no question of accidental intent.

Although files will be read by programs more than humans, text formats 
frequently admit flexible use of linear white space. When going against 
convention it is best to alert readers explicitly.

  -- Ken Shoemake

--------------020208010108070901030609--

Date: Fri, 14 Nov 2008 17:20:34 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] rfc2445bis-09 nit

In section 3.7.3, Product Identifier, the Description says "This 
property SHOULD not"; its capitalization needs to be changed to "This 
property SHOULD NOT", according to the nit finder.

Also there is some complaint about boilerplate which may deserve attention.

  -- Ken

Date: Fri, 14 Nov 2008 09:39:02 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Ken Shoemake <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09

Hi Ken,

See answer inline.

Ken Shoemake wrote:
> With regard to syntax, first some context:
> 
> Note that rfc4234 on ABNF says (section 3.1)
>    ----------
>    LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing
>    model.  A string of contiguous characters (values) is parsed
>    according to the rules defined in ABNF.  For Internet specifications,
>    there is some history of permitting linear white space (space and
>    horizontal tab) to be freely and implicitly interspersed around major
>    constructs, such as delimiting special characters or atomic strings.
> 
>    NOTE:
> 
>       This specification for ABNF does not provide for implicit
>       specification of linear white space.
> 
>    Any grammar that wishes to permit linear white space around
>    delimiters or string segments must specify it explicitly.
>    ----------
> One way to convey that implicit white space is not allowed is to state 
> that the ABNF uses this newer rfc4234 instead of rfc2234; that's obscure 
> and error prone compared to explicitly stating the intent.

The draft already makes reference to RFC5234 (which obsoleted RFC4234):

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-1

  > The memo also includes a formal grammar for the content type based on
  > the Internet ABNF defined in [RFC5234].

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-2

  > The notation used in this memo is the ABNF notation of [RFC5234].

> 
> 
> So now the question:
> 
> In rfc2445, line folding is specified, but beyond that the explicit ABNF 
> syntax apparently does not permit white space between tokens. For example,
>   BEGIN:VEVENT
> would be correct but
>   BEGIN: VEVENT
> would not. A robust parser will accept the latter anyway, but the spec 
> might best spell out the intent: is such white space definitely allowed 
> or definitely disallowed?
> 
> Also:
> The IETF-Tools page (<http://tools.ietf.org/>) provides two tools for 
> automatically combing through the ABNF in a specification (here, 
> 'draft-ietf-calsify-rfc2445bis-09'). The first extracts lines of syntax; 
> it is Bill Fenner's 'aex' (<http://tools.ietf.org/abnf/>). 
> Unfortunately, the current draft causes it to stumble in a few places. 
> The second tool parses ABNF for errors; it is Bill's ABNF Parser, 'bap' 
> (<http://tools.ietf.org/tools/bap/abnf.cgi>). It finds issues with the 
> ABNF in the spec even after the obvious problems left by aex are cleaned 
> up.

Please clarify which issues are reported. Bill's ABNF Parser currently 
reports "No errors during parsing". That being said, it is reporting 
multiple differences between the original and Bill's "canonical" form. 
For instance, the draft currently specifies:

   "BEGIN" ":" "VCALENDAR"

instead of:

   "BEGIN:VCALENDAR"

Is this what you're making reference to?

 > Nevertheless, its strict read of the grammar seems to imply that
> white space between tokens is not formally allowed at present.
> 
> Is there intent to make automatic extraction and parsing of the ABNF 
> work?

I've been using Julian Reschke's "extract-artwork.xslt" transformation 
against the XML version of the draft to extract ABNF from the draft. See:

http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork

I was not aware of the existence of the 'aex' tool. How do you recommend 
to modify the draft such that 'aex' won't pick up the following lines by 
mistake:

   > c=US???(cn=Jim%20Dolittle)":mailto:[email-masked]
   >
   > TZID=America/New_York:19980119T020000
   >
   > FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
   >
   > BYMINUTE=30
   >
   > FREQ=DAILY;COUNT=10;INTERVAL=2
   >
   > TZID=America/New_York:083000
   >
   > decimal = degrees + minutes/60 + seconds/3600.
   >
   > c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
   >
   > BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
   > BYDAY=MO,WE,FR
   >
   > BYMONTHDAY=2,3,4,5,6,7,8

> Is there intent to clarify the permissibility of white space 
> between tokens?

Given that we are already making reference to RFC5234, and that our 
intent is NOT to permit linear white space around delimiters or string 
segments, what change or clarifying text would you like to see added in 
the draft?

Thanks,
Bernard

> -- Ken Shoemake

Date: Fri, 14 Nov 2008 03:30:19 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] ABNF intent in rfc2445bis-09

With regard to syntax, first some context:

Note that rfc4234 on ABNF says (section 3.1)
   ----------
   LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing
   model.  A string of contiguous characters (values) is parsed
   according to the rules defined in ABNF.  For Internet specifications,
   there is some history of permitting linear white space (space and
   horizontal tab) to be freely and implicitly interspersed around major
   constructs, such as delimiting special characters or atomic strings.

   NOTE:

      This specification for ABNF does not provide for implicit
      specification of linear white space.

   Any grammar that wishes to permit linear white space around
   delimiters or string segments must specify it explicitly.
   ----------
One way to convey that implicit white space is not allowed is to state 
that the ABNF uses this newer rfc4234 instead of rfc2234; that's obscure 
and error prone compared to explicitly stating the intent.

So now the question:

In rfc2445, line folding is specified, but beyond that the explicit ABNF 
syntax apparently does not permit white space between tokens. For example,
  BEGIN:VEVENT
would be correct but
  BEGIN: VEVENT
would not. A robust parser will accept the latter anyway, but the spec 
might best spell out the intent: is such white space definitely allowed 
or definitely disallowed?

Also:
The IETF-Tools page (<http://tools.ietf.org/>) provides two tools for 
automatically combing through the ABNF in a specification (here, 
'draft-ietf-calsify-rfc2445bis-09'). The first extracts lines of syntax; 
it is Bill Fenner's 'aex' (<http://tools.ietf.org/abnf/>). 
Unfortunately, the current draft causes it to stumble in a few places. 
The second tool parses ABNF for errors; it is Bill's ABNF Parser, 'bap' 
(<http://tools.ietf.org/tools/bap/abnf.cgi>). It finds issues with the 
ABNF in the spec even after the obvious problems left by aex are cleaned 
up. Nevertheless, its strict read of the grammar seems to imply that 
white space between tokens is not formally allowed at present.

Is there intent to make automatic extraction and parsing of the ABNF 
work? Is there intent to clarify the permissibility of white space 
between tokens?

-- Ken Shoemake

Date: Thu, 13 Nov 2008 00:57:34 -0500
From: Ken Shoemake <[email-masked]>
To: iCalendar group <[email-masked]>
Subject: [ietf-calsify] Test post

My first two posts to this list have not appeared. This is a test.

  -- Ken Shoemake

Date: Thu, 13 Nov 2008 11:21:11 -0500
From: Ken Shoemake <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] Pulling hair

Three prior posts have failed to reach the list. Fourth time the charm?

  -- Ken Shoemake

To: Caleb Richardson <[email-masked]>
Date: Sun, 9 Nov 2008 13:43:47 -0500
From: "Robert Ransdell" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review

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

It does not work for bumping sequence number only on entire recurrence=20
set.
When individual occurrences are rescheduled,  the chair needs to check for =

next sequence number over entire set and set that sequence just for that=20
occurrence one past the last sequence number used .  The invitees will=20
accept that occurrence reschedule and return an accept/decline using that=20
sequence number.  The chair matches response on sequence number for=20
occurrence and marks status updated/decline for that occurrence.=20

From:
Caleb Richardson <[email-masked]>
To:
[email-masked]
Date:
11/07/2008 10:39 PM
Subject:
[ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review
Sent by:
[email-masked]

Issue 9 of Reinhold Kainhofer's iTIP Review

Hello,

I have an issue with the changes recently made in rfc2445bis-09 and=20
2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Review.

In <draft-ietf-calsify-rfc2445bis-09 section 3.8.7.4. Sequence Number>=20
the following statement was added:

"Recurrence instances of a recurring component MAY have different=20
sequence numbers."

There were also some changes made to <draft-ietf-calsify-2446bis-08=20
section 2.1.5. Message Sequencing>, although I am still trying to=20
determine the implications of those changes.

As discussed in this thread started by Cyrus Daboo (it occurred on this=20
mailing list in October 2007):=20
http://osdir.com/ml/ietf.calsify/2007-10/msg00004.html, there are severe=20
consequences if two CUAs differ on their opinion of how to increment=20
SEQUENCE. There is a good example of potential problems in that thread,=20
and I believe the conclusion was that keeping one SEQUENCE per=20
recurrence set was the superior approach.

--=20
Caleb Richardson
Everyone.net
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

<font size=3D2 face=3D"sans-serif">It does not work for bumping sequence nu=
mber
only on entire </font><tt><font size=3D2>recurrence</font></tt><font size=
=3D2 face=3D"sans-serif">set.</font><br><font size=3D2 face=3D"sans-serif">=
When individual occurrences are rescheduled,
&nbsp;the chair needs to check for next sequence number over entire set
and set that sequence just for that occurrence one past the last sequence
number used . &nbsp;The invitees will accept that occurrence reschedule
and return an accept/decline using that sequence number. &nbsp;The chair
matches response on sequence number for occurrence and marks status updated=
/decline
for that occurrence. </font><br><br><br><table width=3D100%><tr valign=3Dto=
p><td><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">From:</font><td><f=
ont size=3D1 face=3D"sans-serif">Caleb Richardson &lt;[email-masked]&gt=
;</font><tr valign=3Dtop><td><font size=3D1 color=3D#5f5f5f face=3D"sans-se=
rif">To:</font><td><font size=3D1 face=3D"sans-serif">ietf-calsify@osafound=
ation.org</font><tr valign=3Dtop><td><font size=3D1 color=3D#5f5f5f face=3D=
"sans-serif">Date:</font><td><font size=3D1 face=3D"sans-serif">11/07/2008 =
10:39 PM</font><tr valign=3Dtop><td><font size=3D1 color=3D#5f5f5f face=3D"=
sans-serif">Subject:</font><td><font size=3D1 face=3D"sans-serif">[ietf-cal=
sify] Issue 9 of Reinhold Kainhofer's
iTIP Review</font><tr valign=3Dtop><td><font size=3D1 color=3D#5f5f5f face=
=3D"sans-serif">Sent by:</font><td><font size=3D1 face=3D"sans-serif">ietf-=
[email-masked]</font></table><br><hr noshade><br><br><br=
><tt><font size=3D2>Issue 9 of Reinhold Kainhofer's iTIP Review<br><br>Hell=
o,<br><br>I have an issue with the changes recently made in rfc2445bis-09 a=
nd <br>2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Revie=
w.<br><br>In &lt;draft-ietf-calsify-rfc2445bis-09 section 3.8.7.4. Sequence=
 Number&gt;
<br>the following statement was added:<br><br>&quot;Recurrence instances of=
 a recurring component MAY have different
<br>sequence numbers.&quot;<br><br>There were also some changes made to &lt=
;draft-ietf-calsify-2446bis-08
<br>section 2.1.5. Message Sequencing&gt;, although I am still trying to <b=
r>determine the implications of those changes.<br><br>As discussed in this =
thread started by Cyrus Daboo (it occurred on this
<br>mailing list in October 2007): <br></font></tt><a href=3D"http://osdir.=
com/ml/ietf.calsify/2007-10/msg00004.html"><tt><font size=3D2>http://osdir.=
com/ml/ietf.calsify/2007-10/msg00004.html</font></tt></a><tt><font size=3D2=
>,
there are severe <br>consequences if two CUAs differ on their opinion of ho=
w to increment <br>SEQUENCE. There is a good example of potential problems =
in that thread,
<br>and I believe the conclusion was that keeping one SEQUENCE per <br>recu=
rrence set was the superior approach.<br><br>-- <br>Caleb Richardson<br>Eve=
ryone.net<br>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F<br>ietf-calsify mailing list<br>[email-masked]<br></=
font></tt><a href=3D"http://lists.osafoundation.org/mailman/listinfo/ietf-c=
alsify"><tt><font size=3D2>http://lists.osafoundation.org/mailman/listinfo/=
ietf-calsify</font></tt></a><tt><font size=3D2><br></font></tt><br><BR>
--=_alternative 00616BDD852574FC_=--

Date: Fri, 07 Nov 2008 19:02:26 -0800
From: Caleb Richardson <[email-masked]>
To: [email-masked]
Subject: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review

Issue 9 of Reinhold Kainhofer's iTIP Review

Hello,

I have an issue with the changes recently made in rfc2445bis-09 and 
2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Review.

In <draft-ietf-calsify-rfc2445bis-09 section 3.8.7.4. Sequence Number> 
the following statement was added:

"Recurrence instances of a recurring component MAY have different 
sequence numbers."

There were also some changes made to <draft-ietf-calsify-2446bis-08 
section 2.1.5. Message Sequencing>, although I am still trying to 
determine the implications of those changes.

As discussed in this thread started by Cyrus Daboo (it occurred on this 
mailing list in October 2007): 
http://osdir.com/ml/ietf.calsify/2007-10/msg00004.html, there are severe 
consequences if two CUAs differ on their opinion of how to increment 
SEQUENCE. There is a good example of potential problems in that thread, 
and I believe the conclusion was that keeping one SEQUENCE per 
recurrence set was the superior approach.

-- 
Caleb Richardson
Everyone.net

Date: Tue, 04 Nov 2008 14:59:47 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-calsify] Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard

Hi,

--On November 4, 2008 11:00:39 AM -0800 The IESG <[email-masked]> 
wrote:

> The IESG has received a request from the Calendaring and Scheduling
> Standards Simplification WG (calsify) to consider the following document:

FYI last call of 2446bis was inadvertently asked for and has now been 
cancelled, so please ignore the above.

To clarify, the -08 draft I posted yesterday contains many changes in 
response to Lisa's and Reinhold's reviews. Still outstanding are a bunch of 
"complex" issues from Reinhold's review. These will need more discussion. I 
will start posting these to the list soon so that we can work through them 
to resolution. The files on the wiki show the current status of dealing 
with Reinhold's issues: 
<http://trac.tools.ietf.org/wg/calsify/trac/wiki/RFC2446bis>.

-- 
Cyrus Daboo

To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Date: Tue,  4 Nov 2008 11:01:25 -0800 (PST)
Cc: [email-masked]
Subject: [ietf-calsify] Last Call: draft-ietf-calsify-rfc2445bis (Internet Calendaring and Scheduling Core Object Specification (iCalendar)) to Proposed Standard
Reply-To: [email-masked]

The IESG has received a request from the Calendaring and Scheduling 
Standards Simplification WG (calsify) to consider the following document:

- 'Internet Calendaring and Scheduling Core Object Specification 
   (iCalendar) '
   <draft-ietf-calsify-rfc2445bis-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-11-18. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13988&rfc_flag=0

To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Date: Tue,  4 Nov 2008 11:00:39 -0800 (PST)
Cc: [email-masked]
Subject: [ietf-calsify] Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard
Reply-To: [email-masked]

The IESG has received a request from the Calendaring and Scheduling 
Standards Simplification WG (calsify) to consider the following document:

- 'iCalendar Transport-Independent Interoperability Protocol (iTIP) '
   <draft-ietf-calsify-2446bis-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-11-18. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-08.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13952&rfc_flag=0

From: [email-masked]
To: [email-masked]
Date: Mon,  3 Nov 2008 13:15:02 -0800 (PST)
Cc: [email-masked]
Subject: [ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-08.txt

--NextPart

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

	Title           : iCalendar Transport-Independent Interoperability Protocol (iTIP)
	Author(s)       : C. Daboo
	Filename        : draft-ietf-calsify-2446bis-08.txt
	Pages           : 130
	Date            : 2008-11-03

This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between
different calendaring systems.  This is done without reference to a
specific transport protocol so as to allow multiple methods of
communication between systems.  Subsequent documents will define
profiles of this protocol using specific interoperable methods of
communications between systems.

iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current
calendaring systems.  These scheduling methods permit two or more
calendaring systems to perform transactions such as publish,
schedule, reschedule, respond to scheduling requests, negotiation of
changes or cancel.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-calsify-2446bis-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Mon, 03 Nov 2008 11:03:29 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Daniel Gomez Brito <[email-masked]>
Cc: IETF Calsify <[email-masked]>, [email-masked]
Subject: Re: [ietf-calsify] [ietf-caldav] Question about recurring tasks.

BTW, I just found the following info in the Calsify Working Group 
Minutes for July 12, 2006:

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

 > 7 Is DTSTART required in VTODO and VJOURNAL components when the RRULE
 > or EXRULE properties are defined in those components?
 >
 > Cyrus floated another idea that in the case of VTODO, perhaps the
 > recurrence could use the DUE property. Bernard suggested that perhaps
 > in the absence of DTSTART, it could default to DUE.
 >
 > Lisa pointed out that this needs more discussion beyond the room,
 > because different apps behave differently.
 >
 > In the end, some agreement that it's enough to clarify that for
 > recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even
 > if it's otherwise optional.
 >
 > AI: Go forward with above clarification

The clarification (issue 24) was made in the section that covers 
"DTSTART", see:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-09.changes.html#rfc.issue.#issue29+dtstart_in_recur_vtodo_and_vjournal

I believe similar text should appear in the "RRULE" section as well...

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Hi Daniel,
> 
> In section 4.8.5.4 Recurrence Rule of RFC 2445 it says:
> 
>  > The recurrence set is generated by considering the initial "DTSTART"
>  > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE"
>  > properties contained within the iCalendar object.
> 
> As such, the "DTSTART" should always be specified in a calendar 
> component that also specify the "RRULE" property.
> 
> That being said, this should probably be stated more clearly in rfc2445bis.
> 
> To be very clear, in iCalendar recurrence instances of a recurring 
> "VTODO" are not computed based on the "DUE" property of the master 
> component.
> 
> So to answer your question, a strict implementation should handle a 
> recurring task with no "DTSTART" as an invalid "VTODO" component, and a 
> relax implementation could probably fix the invalid "VTODO" component by 
> adding the missing "DTSTART" property with the same value as "DUE".
> 
> Cheers,
> Bernard
> 
> Daniel Gomez Brito wrote:
>> Hello:
>>
>>  
>>
>> What’s the proper way to treat a recurring task with no dtstart property?
>>
>> It doesn’t make sense to me but it seems there’s a bunch of portable 
>> devices that let you build something like this:
>>
>>  
>>
>> BEGIN:VCALENDAR
>>
>> VERSION:2.0
>>
>> PRODID:-//Test//Ver 1.0.0 //ES
>>
>> BEGIN:VTODO
>>
>> SUMMARY:cxcx
>>
>> DESCRIPTION:xcx
>>
>> CATEGORIES:
>>
>> CLASS:PUBLIC
>>
>> DUE;VALUE=DATE:20081030
>>
>> PRIORITY:5
>>
>> ORGANIZER:
>>
>> PERCENT-COMPLETE:0
>>
>> STATUS:NEEDS-ACTION
>>
>> RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH
>>
>> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
>>
>> X-FUNAMBOL-ALLDAY:1
>>
>> UID:20081028T082036Z-2
>>
>> DTSTAMP:20081028T082035Z
>>
>> END:VTODO
>>
>> END:VCALENDAR
>>
>>  
>>
>> Regards.
>>
>>  
>>
>> ------------------------------------------------------------------------
>> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede 
>> contener información clasificada por su emisor como confidencial en el 
>> marco de su Sistema de Gestión de Seguridad de la Información siendo 
>> para uso exclusivo del destinatario, quedando prohibida su divulgación 
>> copia o distribución a terceros sin la autorización expresa del 
>> remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo 
>> notifique al remitente y proceda a su borrado. Gracias por su 
>> colaboración.
>> ------------------------------------------------------------------------
>> This message including any attachments may contain confidential 
>> information, according to our Information Security Management System, 
>> and intended solely for a specific individual to whom they are 
>> addressed. Any unauthorised copy, disclosure or distribution of this 
>> message is strictly forbidden. If you have received this transmission 
>> in error, please notify the sender immediately and delete it.
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> ietf-caldav mailing list -- [email-masked]
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 
> 

Date: Mon, 03 Nov 2008 10:46:20 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Daniel Gomez Brito <[email-masked]>
Cc: IETF Calsify <[email-masked]>, [email-masked]
Subject: Re: [ietf-calsify] [ietf-caldav] Question about recurring tasks.

Hi Daniel,

In section 4.8.5.4 Recurrence Rule of RFC 2445 it says:

 > The recurrence set is generated by considering the initial "DTSTART"
 > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE"
 > properties contained within the iCalendar object.

As such, the "DTSTART" should always be specified in a calendar 
component that also specify the "RRULE" property.

That being said, this should probably be stated more clearly in rfc2445bis.

To be very clear, in iCalendar recurrence instances of a recurring 
"VTODO" are not computed based on the "DUE" property of the master 
component.

So to answer your question, a strict implementation should handle a 
recurring task with no "DTSTART" as an invalid "VTODO" component, and a 
relax implementation could probably fix the invalid "VTODO" component by 
adding the missing "DTSTART" property with the same value as "DUE".

Cheers,
Bernard

Daniel Gomez Brito wrote:
> Hello:
> 
>  
> 
> What’s the proper way to treat a recurring task with no dtstart property?
> 
> It doesn’t make sense to me but it seems there’s a bunch of portable 
> devices that let you build something like this:
> 
>  
> 
> BEGIN:VCALENDAR
> 
> VERSION:2.0
> 
> PRODID:-//Test//Ver 1.0.0 //ES
> 
> BEGIN:VTODO
> 
> SUMMARY:cxcx
> 
> DESCRIPTION:xcx
> 
> CATEGORIES:
> 
> CLASS:PUBLIC
> 
> DUE;VALUE=DATE:20081030
> 
> PRIORITY:5
> 
> ORGANIZER:
> 
> PERCENT-COMPLETE:0
> 
> STATUS:NEEDS-ACTION
> 
> RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH
> 
> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
> 
> X-FUNAMBOL-ALLDAY:1
> 
> UID:20081028T082036Z-2
> 
> DTSTAMP:20081028T082035Z
> 
> END:VTODO
> 
> END:VCALENDAR
> 
>  
> 
> Regards.
> 
>  
> 
> ------------------------------------------------------------------------
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede 
> contener información clasificada por su emisor como confidencial en el 
> marco de su Sistema de Gestión de Seguridad de la Información siendo 
> para uso exclusivo del destinatario, quedando prohibida su divulgación 
> copia o distribución a terceros sin la autorización expresa del 
> remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo 
> notifique al remitente y proceda a su borrado. Gracias por su colaboración.
> ------------------------------------------------------------------------
> This message including any attachments may contain confidential 
> information, according to our Information Security Management System, 
> and intended solely for a specific individual to whom they are 
> addressed. Any unauthorised copy, disclosure or distribution of this 
> message is strictly forbidden. If you have received this transmission in 
> error, please notify the sender immediately and delete it.
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav