[Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify

[Dave Thewlis]

Cyrus, Reinhold, Sam,

I've added some text to the questionnaire text as a result of the points
that have been raised to try and make it clearer.  First to make Cyrus'
point about production and consumption, and second to say that if you
can't reasonably answer either Yes or No, please leave the YES/NO
question blank but explain issue in the comment area to help us
understand.  I hope this helps a bit.  We'll still try to answer
questions as they arise.

Dave


Cyrus Daboo wrote:

> Hi Reinhold,
>
> --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer 
> <reinhold at kainhofer.com> wrote:
>
>>> Does yes mean I comply on generation? That I fail on processing if the
>>> MUST is violated? If I try to recover from non-compliant calendars
>>> during decoding, does that make me a "no"?
>>
>
> Strictly speaking the MUST in the specs refers to both consumption and 
> production of the relevant items - to be compliant you have to do both 
> correctly. So for the time being I think you should answer YES only if 
> you produce and consume the item correctly (or if your implementation 
> only does one thing - i.e. just consumes - then answer YES to that if 
> it conforms). Ignore any behaviour for non-compliant data being consumed.
>
>>> Also, I'd think an interesting question would be what FREQ values 
>>> people
>>> have actually implemented. For example, I haven't implemented a FREQ of
>>> WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on my todo 
>>> list,
>>> but since I haven't seen a calendar with these yet,
>>
>
> FYI the technical committee is working on a second questionnaire that 
> will list each of the syntactical elements for recurrences and ask 
> yes/no questions for separately for 'consume' and 'produce' of those. 
> I'm nor sure when we will have that available - in the meantime please 
> go ahead and fill out the current form if you've not already done so - 
> thanks.
>
>>> If nobody supported BYSETPOS it would be a candidate for removal from
>>> the update prior to standardization. If its just me, then I better
>>> implement it soon!
>>
>>
>> libkcal and thus all KDE applications also don't implement BYSETPOS yet.
>> It's  also on my to-do list, but I don't think I'll have the time to
>> implement it  in the short- or midterm future.
>
>
> FYI my implementation is capable of consuming and producing BYSETPOS, 
> though the UI limits the range that can be produced by the user. 
> Implementing BYSETPOS was probably the hardest part of doing the rules 
> as it meant pretty much having to expand the entire possible set and 
> then picking the ones matched in order to support negative BYSETPOS 
> values. It makes incremental or iterative recurrence expansion hard to 
> do without keeping a lot of state information around.
>