bernhard at intevation.de
Mon Feb 27 13:28:42 CET 2006
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
p103) The clients shall preserve the saved value, even when
using a different mapping for display, if the priority is not
Joon, Till, Johannes:
What do you think?
Am Donnerstag, 23. Februar 2006 20:28 schrieb Martin Konold:
> Am Mittwoch, 22. Februar 2006 18:37 schrieb Bernhard Reiter:
> > 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
> I definetly consider to invent a third standard a bug especially because we
> explicitly want interoperability.
> -- martin
More information about the format