priority specification

[Bernhard Reiter]

Martin and I found the time to spend time on the phone
in order to help the progressing things.

The reason why we should touch the specification regarding priorities is:
Currently interoperability is broken as the clients interpret 
our 1 to 5 range differently. 

So when we need to touch the clients anyway soon, 
we can as well try to do the right thing here.

Martin and I agree that
* users do not need more then three priorities in practice.
* We should stay as close to the standards as possible.
* We shall not break the Outlook user interface.

The possibility we propose is:
p101) Save the priority as 10 values as RFC 2445 suggests:
          0 = no priority selected
          1-9 = priorities, with 1 being higest

p102) The clients have a choice of how to display those ten values
          in principle. If a mapping is used towards low,  middle, high,
          RFC2445 mapping must be used.
 
         We suggest to use the mapping of RFC 2445 for 
 	  low, middle, high and "no selection" for all clients with
          "no-selection" displayed and sorted as "middle" it not possible
         otherwise.

p103) The clients shall preserve the saved value, even when 
           using a different mapping for display, if the priority is not 
           changed.

Joon, Till, Johannes:
What do you think?

Bernhard

Am Donnerstag, 23. Februar 2006 20:28 schrieb Martin Konold:
> Am Mittwoch, 22. Februar 2006 18:37 schrieb Bernhard Reiter:
>
> Hi,
>
> > 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.
>
> In short we have two standards. The MS Outlook industrie standard and the
> 2445.
>
> I definetly consider to invent a third standard a bug especially because we
> explicitly want interoperability.
>
> Regards,
> -- martin