priority specification bug

[Bernhard Reiter]

Hi Martin,

Am Dienstag, 14. Februar 2006 06:12 schrieb Martin Konold:
> we need a solution for priorities.
>
> KO: 1-9 (*) with 1 being highest
> OL: low, normal, high
> Kolab Format Specification: 1-5 with 1 being highest.
> ical rfc 2445: 0-9 with 1 being highest
>
> This situation is beyond my understanding. Does anyone know why the Kolab
> Format Specification
> http://www.kolab.org/doc/kolabformat-2.0rc3-html/c254.html has defined the
> 1-5 range? Is this a plain bug?

No, it was done on purpose as I darkly remember
(with you also being part of the discussion group.)
The reason as I remember it were that the user actually would not want 
to have too many priorities and with 1 to 5 a good mapping between 
Kolab (which onyl does 1 to 5) and outlook is done.

I would ask back why KO changed back to 1-9 in non-kolab branches. ;-)

> I see two solutions:
>
> 1.) change the Kolab format specification to the common denominator. (OL
> behaviour with only three values)
>
> 2.) use a mapping which tries to preserve as much information as possible
> but which is "lossy" in some case. This means changing the spec to use 9
> values. (**)

I think we use a mapping already from 1-5 to high, medium low.

> All: Do you agree that the current Kolab Format Specification for
> priorities using five values is simply a bug and violating any standard
> including KO,OL and ical RFC 2445?

I would be interested in more reasons why this is a problem,
on first sight I would consider iCal RFC and KO to have too many priorities.

> David: Do you consider 1.) a possible solution?
>
> Joon,Johannes: In case 2.) will adopted are you willing to add the required
> complexity to your products soon?
>
> I personally think that 1.) is fully sufficient as choosing between 10
> priority values is imho overengineered but using 10 levels (0+1-9 with 0
> being undefined) is defined in the ical RFC and therefore a real standard.

For what it is worth, I also consider 1) fine, but we would need to convince
the whole KDEPIM gang, not just David.

> (*) To add to the confusion 1 is mapped to highest and 9 to lowest
> priority.
>
> (**) It shall be a best effort approach preserving as much information as
> possible while being lossless in non-mixed environments. If
> transformation/mapping is required (the priority property is
> written/modified) then the mapping rules are already defined in RFC 2445.