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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Sun Apr 3 11:52:02 2005

Just one little bug - or rather niggly - is that it is rather difficult
in an HTML form to deselect all options in a set of radio buttons,
therefore the approach of "don't select either" is somewhat problematic
in the cases where you may have already chosen one (for whatever reason)
- without completely resetting the form to try again. :)

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave
Thewlis
Sent: Sunday.03.April.2005 10.37
To: Cyrus Daboo
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on
implementationof Recurrence Rules -- Calconnect and Calsify

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 
> <[email-masked]> 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.
>

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

---

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

An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/babef462/attachment.htm

---

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

An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/67d3d91c/attachment.htm

---

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

Hi Cameron,

> - without completely resetting the form to try again. :)

Right - I think what we need is a three-state choice: 'yes', 'no', 'n/a' 
(not applicable for whatever reason - e.g. question about iTIP but product 
does not implement iTIP at all).

-- 
Cyrus Daboo

---

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Sun Apr 3 15:50:14 2005

I made it "YES" "NO" and "OTHER" which amounts to the same thing.  Now 
up on the site. 

Cyrus Daboo wrote:

> Right - I think what we need is a three-state choice: 'yes', 'no', 
> 'n/a' (not applicable for whatever reason - e.g. question about iTIP 
> but product does not implement iTIP at all).
>