Pre-KEP input sought: Priority for events? (in line with tasks?)(similar to VEVENT & VTODO?)

[Georg C. F. Greve]

Hi all,

A customer has approached us with the request to store event priority 
information, similar to what is allowed in iCalendar:

   http://www.rfc-editor.org/rfc/rfc5545.txt

   3.8.1.9.  Priority

   Property Name:  PRIORITY

   Purpose:  This property defines the relative priority for a calendar
      component.

   Value Type:  INTEGER

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property can be specified in "VEVENT" and "VTODO"
      calendar components.

   Description:  This priority is specified as an integer in the range 0
      to 9.  A value of 0 specifies an undefined priority.  A value of 1
      is the highest priority.  A value of 2 is the second highest
      priority.  Subsequent numbers specify a decreasing ordinal
      priority.  A value of 9 is the lowest priority.

      A CUA with a three-level priority scheme of "HIGH", "MEDIUM", and
      "LOW" is mapped into this property such that a property value in
      the range of 1 to 4 specifies "HIGH" priority.  A value of 5 is
      the normal or "MEDIUM" priority.  A value in the range of 6 to 9
      is "LOW" priority.


According to what I could find in the specification, priority is only available 
in the 'task' object, and then only in a range of 1-5, with 1 as the highest 
priority. The '0' for 'undefined' does not appear to exist.

So here are the questions:

 (a) Does anyone else have this requirement, and particular cases they
	would request to have taken into account?

 (b1) Should we add priority to the 'event' object type?

 (b2) Or should we move priority one level up from 'task' into the common 
fields in events and tasks, of which there are already several?

 (c1) Should we implement the 0-9 priorities of iCalendar?

 (c2) Or should we stay with the 1-5 approach?

Advantage of (c1) would obviously be better compatibility with iCalendar and 
iTip, while (c2) would mean full legacy compatibility. But then we 
(necessarily) have two breaking changes already, and this is a fairly small 
one that we might just add to the changeset.

And (b2) obviously has the advantage (besides being compatible with VTODO) of 
one definition for the entire set of objects, over two separate (and in the 
worst future case, diverging) definitions.

And even when choosing (b2) would older datasets continue to work.

So I guess I'm currently having a slight preference for (b2) (c1).

But I'd very much like to get input from others, as well.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110531/845c596a/attachment.sig>