RFC2822 windows attachment

Reinhold Kainhofer reinhold at kainhofer.com
Tue Feb 1 11:40:16 CET 2005

On Friday 28 January 2005 06:12, Joon Radley wrote:
> > E.g.
> > the importance or the reply-date are imho nice features which
> > can benefit the user in cross platform usage szenarios. (E.g
> > a shared folder for a helpdesk)
> >
> > - entryid

What is the entry id exactly?

> > - reply-date
> > - sent-date
> > - sent-representing
> > - received representing.

These would be nice to have them in the format specification anyway. 
Unfortunately, rfc 2445 (iCalendar) doesn't specify this, so there's no real 
way to use them accross CUAs... I guess these are properties of each 
attendee, right? If so, shouldn't they be stored with each attendee?

> Either the fields are already defined my RFC2822 or are of no relevance to
> the RFC2822/IMAP4 storage.
> The following field are not defined and will greatly enhance
> interoperability:
> > - importance (richer than the plain imap flag)
> Importance = "x-kolab-importance" ":" "low" | "normal" | "high"

In how far is this different from the iCalendar priority (0-9 in KOrganizer, 
mapped to low|normal|high in Outlook), which is also defined in the kolab 
format for Tasks?

> - follow-up ( flagged to follow-up )
> Follow-up = "x-kolab-follow-up" ":" "red" | "blue" | "yellow" | "green" |
> "orange" | "purple" | "completed"

Why do you want to use colors? Wouldn't it be better to specify generic terms 
and the connector then translates these to colors?

> The issue I am trying to address with the attachment is custom fields
> created by custom plug-ins in Outlook. 

And for each new custom plug-in you need to extend the spec / header further? 
Wouldn't it be simpler to define a way to store custom x-* properties inside 
the item (i.e. define it in the kolab spec). That's exactly the use case that 
was meant for the xustom properties...


Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20050201/566bedd3/attachment.sig>

More information about the format mailing list