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

From: dthewlis at dcta.com (David C. Thewlis)
Date: Sat Apr 2 06:30:25 2005

An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050402/95f848dc/attachment.htm

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 3 09:21:07 2005

> URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050402/95f848dc/attachment.htm

Hi,

I'm an implementor of iCalendar support for ruby, and I've implemented
recurrence rules. Its a toolkit, not an application (though it comes
with some utilities, and I am working towards a number of stand-alone
applications that will use the toolkit for calendaring support). Also,
the encoding side is regrettably quite raw still, so it allows very
definitely non-compliant calendars to be generated. I need better APIs
to make it harder for people to generate bad calendars (on my todo
list).

Anyhow, I'm not sure how to fill out the form.

For one thing generate and process (encode/decode) support are seperate
issues, I think.

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"?

I.e., I might never generate an event where STATUS appears more than
once, but accept an event where STATUS occurs twice, and discard the
second occurrence.

What would I tick in 4.6.1a, yes or no?

Another example is for an RRULE, what would I say about 4.3.10b? I
don't/can't process an RRULE without a FREQ. I just took a look at the
code, though, it appears that I allow multiple FREQ, and will use the
last one I see.

So, do I tick yes or no?

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, and nobody using
vPim has asked for it, they have slipped down the priority list. WEEKLY
will take some work, BYHOUR/min/SEC is just a bit of fill-in-the-blanks
coding.

I think this kind of thing would be worthwhile to document, wouldn't it?

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!

Thanks,
Sam

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sun Apr 3 09:31:39 2005

> during decoding, does that make me a "no"?

I had exactly the same questions. David said he'll ask the technical commitee 
about this.

> but since I haven't seen a calendar with these yet, 

Weekly is quite commonly used, e.g. for a course each monday and wednesday, 
your weekly choir rehersal, gym hours etc.

byhour/minute/second is probably hardly ever used in your personal calendar 
(but alarm applications like KAlarm make use of minutely or hourly 
recurrence, e.g. to remind you every hour to get away from your computer for 
a few minutes).

BYSETPOS is needed for recurrences like the last working day of a month.

> the update prior to standardization. If its just me, then I better

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.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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 / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/11692a4d/attachment.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Sun Apr 3 09:49:24 2005

Hi Reinhold,

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

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

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

-- 
Cyrus Daboo

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 3 10:27:30 2005

> Ignore any behaviour for non-compliant data being consumed.

Ok, so the FREQ question means "do you generate the FREQ"?

> out the current form if you've not already done so - thanks.

I'm not sure if its useful, still. I think its fairly app oriented, not
toolkit oriented. You can get a summary from an event with my toolkit,
but it doesn't exactly do anything with it, just gives it to you.

What is the goal, to get somebody to admit they don't write a FREQ when
they generate a calendar?

Or to find somebody who encodes multiple SUMMARY fields? And then what,
make it allowed in 2445bis, or just publicly chastise them? :-)

Sorry for the joke.

Seriously, I want to help out, but I don't know what the questionaire is
trying to find out.

> keeping a lot of state information around.

I think its important, it just dropped down below things like a nice API
to help people generate recuring events.

Cheers,
Sam

---

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Sun Apr 3 10:37:12 2005

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:

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