From volker at kdab.net  Fri Sep 14 12:29:39 2007
From: volker at kdab.net (Volker Krause)
Date: Fri, 14 Sep 2007 12:29:39 +0200
Subject: Fwd: [Kolab-devel] Non-standard IMAP flags in KMail
Message-ID: <200709141229.39285.volker@kdab.net>

Forwarded here as suggested by Bernhard. 

----------  Forwarded Message  ----------

Subject: [Kolab-devel] Non-standard IMAP flags in KMail
Date: Monday 10 September 2007
From: Volker Krause <volker at kdab.net>
To: kolab-devel at kolab.org

Hi,

we have been implemeting support for storing all message status flags of KMail 
on a Kolab server. So far only standard IMAP flags (seen, answered, 
important) haven been stored there. For the non-standard flags (todo, 
forwarded, ignored, watched) I have been looking at what IMAP flags other 
mail clients use for that, with the following results:

- Outlook 2007 is claimed to support only one flag for IMAP items, no idea if 
this is correct (I don't have it here to test it myself), but it would mean 
there is no support for custom IMAP flags. Can anyone confirm this?
- Thunderbird uses $labelN
- there is a draft dealing with extended IMAP flags: 
http://tools.ietf.org/html/draft-melnikov-imap-keywords-03
However, this still does not cover all flags we need (watched and ignored are 
missing).

Has anyone additional information on that topic, ie. which mail client uses 
what additional IMAP flags?

Overall, it seems that $<name> is the "standard" way of dealing with extended 
flags that have a general, not client-specific meaning. So, unless that 
conflicts badly with any other client out there, I would suggest to follow 
that for KMail by using $ToDo, $Forwarded, $Ignored, $Watched.

regards
Volker

-- 
Volker Krause -- volker at kdab.net, vkrause at kde.org
Klar?lvdalens Datakonsult AB, Platform-independent software solutions

-------------------------------------------------------
-- 
Volker Krause -- volker at kdab.net, vkrause at kde.org
Klar?lvdalens Datakonsult AB, Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-format/attachments/20070914/dbcf74c1/attachment.bin

From wrobel at pardus.de  Wed Sep 19 09:52:42 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 19 Sep 2007 09:52:42 +0200
Subject: [Kolab-devel] IMAP annotation for groupware folder descriptions
In-Reply-To: <20070919070730.GB22343.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Wed, 19 Sep 2007 09:07:30 +0200")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200709141013.55119.bernhard@intevation.de>
	<87lkb3fylt.fsf@home.pardus.de>
	<20070919070730.GB22343.thomas@intevation.de>
Message-ID: <87fy1bf5x1.fsf@home.pardus.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:

> * Gunnar Wrobel <wrobel at pardus.de> [20070918 23:33]:
>> If you use MySQL as the Horde backend it is trivial to support the
>> description feature and there will be users using it. So I doubt that
>> it will be removed. It has already existed a long time and has
>> actually always been "supported" by the Kolab driver within Horde
>> (even the old broken ones). The use of
>> "/vendor/kolab/h-share-attr-desc" originates from the older driver
>> versions.
>> 
>> Since it is trivial to support it as an additional annotation on the
>> IMAP server I'm definitely in favor of keeping it but I don't mind if
>> it is not going to be implemented in the other clients. 
>
> That's why I'd prefer /vendor/horde/something ... even if other
> clients will implement it, they will be compatible with this horde
> feature here.

Ah, forgot to comment on that. While the wording in the Kolab format
specification at
http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html#AEN157 is
rather vague about this topic I assume that the intention of the
paragraph on client specific annotations means that Horde should use
"/vendor/kolab/h-*" for its specific features. 

So I'm cross-posting this to kolab-format.

I do believe that we might nevertheless keep the client entries in
"/vendor/kolab/*" since we control what annotation values can actually
be stored on the server. I'd also be fine with using "/vendor/horde"
but then the other client specific attributes would need to be
renamed. I don't know if there actually are any other client specific
annotations being used?

This would be important because the newer IMAP server does not allow
to store abitrary annotations anymore (for security reasons). So we
would need to declare them.

Cheers,

Gunnar

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From thomas at intevation.de  Wed Sep 19 12:05:16 2007
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 19 Sep 2007 12:05:16 +0200
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <87fy1bf5x1.fsf@home.pardus.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200709141013.55119.bernhard@intevation.de>
	<87lkb3fylt.fsf@home.pardus.de>
	<20070919070730.GB22343.thomas@intevation.de>
	<87fy1bf5x1.fsf@home.pardus.de>
Message-ID: <20070919100516.GA1732.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20070919 09:53]:
> Thomas Arendsen Hein <thomas at intevation.de> writes:
> > * Gunnar Wrobel <wrobel at pardus.de> [20070918 23:33]:
> >> If you use MySQL as the Horde backend it is trivial to support the
> >> description feature and there will be users using it. So I doubt that
> >> it will be removed. It has already existed a long time and has
> >> actually always been "supported" by the Kolab driver within Horde
> >> (even the old broken ones). The use of
> >> "/vendor/kolab/h-share-attr-desc" originates from the older driver
> >> versions.
> >
> > That's why I'd prefer /vendor/horde/something ... even if other
> > clients will implement it, they will be compatible with this horde
> > feature here.
> 
> Ah, forgot to comment on that. While the wording in the Kolab format
> specification at
> http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html#AEN157 is
> rather vague about this topic I assume that the intention of the
> paragraph on client specific annotations means that Horde should use
> "/vendor/kolab/h-*" for its specific features. 

Citing the page:

  All folders MUST be annotated with an entry
  /vendor/kolab/folder-type containing the attribute value.shared
  set to: <type>[.<subtype>]

  For other client-specific non standardized types of folders, these
  MUST be prefixed with "k-" for KMail, "h-" for Horde, "o-" for
  Outlook with the Toltec Connector and "ok-" for Outlook with the
  KONSEC Konnektor. E.g. "kolab.o-voicemail".

So this h- thing is only meant for the value of the
/vendor/kolab/folder-type annotation and can be ignored for our
question.

> So I'm cross-posting this to kolab-format.

I hope everyone over there is reading here, too :)

> I do believe that we might nevertheless keep the client entries in
> "/vendor/kolab/*" since we control what annotation values can actually
> be stored on the server. I'd also be fine with using "/vendor/horde"
> but then the other client specific attributes would need to be
> renamed. I don't know if there actually are any other client specific
> annotations being used?

No, this is just the folder-type value and doesn't need to be
renamed.

> This would be important because the newer IMAP server does not allow
> to store abitrary annotations anymore (for security reasons). So we
> would need to declare them.

Which is a good thing, not only for security reasons :)

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From joon at radleys.co.za  Wed Sep 19 14:38:01 2007
From: joon at radleys.co.za (Joon Radley)
Date: Wed, 19 Sep 2007 14:38:01 +0200
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <20070919100516.GA1732.thomas@intevation.de>
References: <87fy1kqa9n.fsf@home.pardus.de>	<200709141013.55119.bernhard@intevation.de>	<87lkb3fylt.fsf@home.pardus.de>	<20070919070730.GB22343.thomas@intevation.de>	<87fy1bf5x1.fsf@home.pardus.de>
	<20070919100516.GA1732.thomas@intevation.de>
Message-ID: <002c01c7fab9$ed98db20$c8ca9160$@co.za>

Hi,

> > This would be important because the newer IMAP server does not allow 
> > to store abitrary annotations anymore (for security reasons). So we 
> > would need to declare them.
> 
> Which is a good thing, not only for security reasons :)

Let me explain the reason for this from the Outlook side. In Outlook anyone
can create a custom folder type or custom messages. This mechanism was
created to provide for custom folder types. Without this mechanism, not all
folders will be uploaded to the sever and the server will no longer be a
backup of the local mail store.

It is not possible to predict what custom folder types there will be.

Best Regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
Web: www.toltec.co.za




From martin.konold at erfrakon.de  Mon Sep 24 07:50:50 2007
From: martin.konold at erfrakon.de (Martin Konold)
Date: Mon, 24 Sep 2007 07:50:50 +0200
Subject: Fwd: [Kolab-devel] Non-standard IMAP flags in KMail
In-Reply-To: <200709141229.39285.volker@kdab.net>
References: <200709141229.39285.volker@kdab.net>
Message-ID: <200709240750.58342.martin.konold@erfrakon.de>

Am Freitag 14 September 2007 schrieb Volker Krause:

Hi Volker,

can you please explain which new commands (if possible verbatim) there will be 
on the IMAP tcp connection?

With which servers did you test?

Regards,
-- martin

> Forwarded here as suggested by Bernhard.
>
> ----------  Forwarded Message  ----------
>
> Subject: [Kolab-devel] Non-standard IMAP flags in KMail
> Date: Monday 10 September 2007
> From: Volker Krause <volker at kdab.net>
> To: kolab-devel at kolab.org
>
> Hi,
>
> we have been implemeting support for storing all message status flags of
> KMail on a Kolab server. So far only standard IMAP flags (seen, answered,
> important) haven been stored there. For the non-standard flags (todo,
> forwarded, ignored, watched) I have been looking at what IMAP flags other
> mail clients use for that, with the following results:
>
> - Outlook 2007 is claimed to support only one flag for IMAP items, no idea
> if this is correct (I don't have it here to test it myself), but it would
> mean there is no support for custom IMAP flags. Can anyone confirm this? -
> Thunderbird uses $labelN
> - there is a draft dealing with extended IMAP flags:
> http://tools.ietf.org/html/draft-melnikov-imap-keywords-03
> However, this still does not cover all flags we need (watched and ignored
> are missing).
>
> Has anyone additional information on that topic, ie. which mail client uses
> what additional IMAP flags?
>
> Overall, it seems that $<name> is the "standard" way of dealing with
> extended flags that have a general, not client-specific meaning. So, unless
> that conflicts badly with any other client out there, I would suggest to
> follow that for KMail by using $ToDo, $Forwarded, $Ignored, $Watched.
>
> regards
> Volker
>
> --
> Volker Krause -- volker at kdab.net, vkrause at kde.org
> Klar?lvdalens Datakonsult AB, Platform-independent software solutions
>
> -------------------------------------------------------


Mit freundlichen Gr??en,
-- martin konold

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23 Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/


From martin.konold at erfrakon.de  Tue Sep 25 07:05:59 2007
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 25 Sep 2007 07:05:59 +0200
Subject: Fwd: [Kolab-devel] Non-standard IMAP flags in KMail
In-Reply-To: <200709240750.58342.martin.konold@erfrakon.de>
References: <200709141229.39285.volker@kdab.net>
	<200709240750.58342.martin.konold@erfrakon.de>
Message-ID: <200709250706.03029.martin.konold@erfrakon.de>

Am Montag 24 September 2007 schrieb Martin Konold:

Hi Volker,

I further investigated this matter.

It looks like you took a totally expired draft (anyone can make up a draft) as 
a guideline.

I am afraid that this draft did not only expire but it also did not get enough 
support fromt he community in order to become a RFC.

Did I overlook some aspect?

Regards,
-- martin
P.S.: - OL2K7 uses more than a single IMAP Flag
      - KONSEC Konnektor for OL would be able to use any available IMAP Flag
        just as kmail.
      - For many purposes a plain boolean flag is not enough. E.g. flags have
        colours and replied has a date....

> Am Freitag 14 September 2007 schrieb Volker Krause:
>
> Hi Volker,
>
> can you please explain which new commands (if possible verbatim) there will
> be on the IMAP tcp connection?
>
> With which servers did you test?
>
> Regards,
> -- martin
>
> > Forwarded here as suggested by Bernhard.
> >
> > ----------  Forwarded Message  ----------
> >
> > Subject: [Kolab-devel] Non-standard IMAP flags in KMail
> > Date: Monday 10 September 2007
> > From: Volker Krause <volker at kdab.net>
> > To: kolab-devel at kolab.org
> >
> > Hi,
> >
> > we have been implemeting support for storing all message status flags of
> > KMail on a Kolab server. So far only standard IMAP flags (seen, answered,
> > important) haven been stored there. For the non-standard flags (todo,
> > forwarded, ignored, watched) I have been looking at what IMAP flags other
> > mail clients use for that, with the following results:
> >
> > - Outlook 2007 is claimed to support only one flag for IMAP items, no
> > idea if this is correct (I don't have it here to test it myself), but it
> > would mean there is no support for custom IMAP flags. Can anyone confirm
> > this? - Thunderbird uses $labelN
> > - there is a draft dealing with extended IMAP flags:
> > http://tools.ietf.org/html/draft-melnikov-imap-keywords-03
> > However, this still does not cover all flags we need (watched and ignored
> > are missing).
> >
> > Has anyone additional information on that topic, ie. which mail client
> > uses what additional IMAP flags?
> >
> > Overall, it seems that $<name> is the "standard" way of dealing with
> > extended flags that have a general, not client-specific meaning. So,
> > unless that conflicts badly with any other client out there, I would
> > suggest to follow that for KMail by using $ToDo, $Forwarded, $Ignored,
> > $Watched.
> >
> > regards
> > Volker


-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23 Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/


From martin.konold at erfrakon.de  Tue Sep 25 07:09:58 2007
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 25 Sep 2007 07:09:58 +0200
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <002c01c7fab9$ed98db20$c8ca9160$@co.za>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<20070919100516.GA1732.thomas@intevation.de>
	<002c01c7fab9$ed98db20$c8ca9160$@co.za>
Message-ID: <200709250710.01493.martin.konold@erfrakon.de>

Am Mittwoch 19 September 2007 schrieb Joon Radley:

Hi,

> Let me explain the reason for this from the Outlook side. In Outlook anyone
> can create a custom folder type or custom messages. This mechanism was
> created to provide for custom folder types. Without this mechanism, not all
> folders will be uploaded to the sever and the server will no longer be a
> backup of the local mail store.

Well, even if you cannot upload arbitrary annoations to the server it does not 
prevent you from uploading the individual mails/objects.

> It is not possible to predict what custom folder types there will be.

What about an "unknown" or "other" keyword in order to allow for this. It 
would then be the duty of the client to do the mapping e.g. using a "hidden" 
mail message.

Regards,
-- martin konold

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23 Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/


From joon at radleys.co.za  Tue Sep 25 07:34:30 2007
From: joon at radleys.co.za (Joon Radley)
Date: Tue, 25 Sep 2007 07:34:30 +0200
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <200709250710.01493.martin.konold@erfrakon.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<20070919100516.GA1732.thomas@intevation.de>
	<002c01c7fab9$ed98db20$c8ca9160$@co.za>
	<200709250710.01493.martin.konold@erfrakon.de>
Message-ID: <000e01c7ff35$c1f559a0$45e00ce0$@co.za>

Hi Martin,

> Well, even if you cannot upload arbitrary annoations to the server it
> does not prevent you from uploading the individual mails/objects.
..
> What about an "unknown" or "other" keyword in order to allow for this.
> It would then be the duty of the client to do the mapping e.g. using a
> "hidden"  mail message.

Then a format rule has to be created for this as some clients might display
the "hidden" message and allow it to be deleted. 

The only minor issue is that now there will be two different ways to
identify he content type of a folder. 

Should we just move completely to the hidden message solution and avoid all
the issue with the annotation database and the fact that it seems that the
annotation extension will not be widely adopted by other IMAP4 servers and
only partially by Cyrus?

Best Regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
Web: www.toltec.co.za




From wrobel at pardus.de  Wed Sep 26 07:11:51 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 26 Sep 2007 07:11:51 +0200
Subject: [Kolab-devel] IMAP annotation for groupware folder descriptions
In-Reply-To: <20070919100516.GA1732.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Wed, 19 Sep 2007 12:05:16 +0200")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200709141013.55119.bernhard@intevation.de>
	<87lkb3fylt.fsf@home.pardus.de>
	<20070919070730.GB22343.thomas@intevation.de>
	<87fy1bf5x1.fsf@home.pardus.de>
	<20070919100516.GA1732.thomas@intevation.de>
Message-ID: <87bqbq80yw.fsf@home.pardus.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:

> * Gunnar Wrobel <wrobel at pardus.de> [20070919 09:53]:
>> Thomas Arendsen Hein <thomas at intevation.de> writes:
>> > * Gunnar Wrobel <wrobel at pardus.de> [20070918 23:33]:
>> >> If you use MySQL as the Horde backend it is trivial to support the
>> >> description feature and there will be users using it. So I doubt that
>> >> it will be removed. It has already existed a long time and has
>> >> actually always been "supported" by the Kolab driver within Horde
>> >> (even the old broken ones). The use of
>> >> "/vendor/kolab/h-share-attr-desc" originates from the older driver
>> >> versions.
>> >
>> > That's why I'd prefer /vendor/horde/something ... even if other
>> > clients will implement it, they will be compatible with this horde
>> > feature here.
>> 
>> Ah, forgot to comment on that. While the wording in the Kolab format
>> specification at
>> http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html#AEN157 is
>> rather vague about this topic I assume that the intention of the
>> paragraph on client specific annotations means that Horde should use
>> "/vendor/kolab/h-*" for its specific features. 
>
> Citing the page:
>
>   All folders MUST be annotated with an entry
>   /vendor/kolab/folder-type containing the attribute value.shared
>   set to: <type>[.<subtype>]
>
>   For other client-specific non standardized types of folders, these
>   MUST be prefixed with "k-" for KMail, "h-" for Horde, "o-" for
>   Outlook with the Toltec Connector and "ok-" for Outlook with the
>   KONSEC Konnektor. E.g. "kolab.o-voicemail".
>
> So this h- thing is only meant for the value of the
> /vendor/kolab/folder-type annotation and can be ignored for our
> question.

Ah, sorry for that. Yes, I misunderstood that paragraph.

So I would propose to change the corresponding attribute to

/vendor/horde/description

if nobody objects.

Cheers,

Gunnar

>
>> So I'm cross-posting this to kolab-format.
>
> I hope everyone over there is reading here, too :)
>
>> I do believe that we might nevertheless keep the client entries in
>> "/vendor/kolab/*" since we control what annotation values can actually
>> be stored on the server. I'd also be fine with using "/vendor/horde"
>> but then the other client specific attributes would need to be
>> renamed. I don't know if there actually are any other client specific
>> annotations being used?
>
> No, this is just the folder-type value and doesn't need to be
> renamed.
>
>> This would be important because the newer IMAP server does not allow
>> to store abitrary annotations anymore (for security reasons). So we
>> would need to declare them.
>
> Which is a good thing, not only for security reasons :)
>
> Thomas
>
> -- 
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
> Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Wed Sep 26 07:32:15 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 26 Sep 2007 07:32:15 +0200
Subject: Declaring a new folder type for Horde preferences (was: [Kolab-devel]
	IMAP annotation for groupware folder descriptions)
In-Reply-To: <20070919100516.GA1732.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Wed, 19 Sep 2007 12:05:16 +0200")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200709141013.55119.bernhard@intevation.de>
	<87lkb3fylt.fsf@home.pardus.de>
	<20070919070730.GB22343.thomas@intevation.de>
	<87fy1bf5x1.fsf@home.pardus.de>
	<20070919100516.GA1732.thomas@intevation.de>
Message-ID: <877ime800w.fsf_-_@home.pardus.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:

> * Gunnar Wrobel <wrobel at pardus.de> [20070919 09:53]:
>> Thomas Arendsen Hein <thomas at intevation.de> writes:
>> > * Gunnar Wrobel <wrobel at pardus.de> [20070918 23:33]:
>> >> If you use MySQL as the Horde backend it is trivial to support the
>> >> description feature and there will be users using it. So I doubt that
>> >> it will be removed. It has already existed a long time and has
>> >> actually always been "supported" by the Kolab driver within Horde
>> >> (even the old broken ones). The use of
>> >> "/vendor/kolab/h-share-attr-desc" originates from the older driver
>> >> versions.
>> >
>> > That's why I'd prefer /vendor/horde/something ... even if other
>> > clients will implement it, they will be compatible with this horde
>> > feature here.
>> 
>> Ah, forgot to comment on that. While the wording in the Kolab format
>> specification at
>> http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html#AEN157 is
>> rather vague about this topic I assume that the intention of the
>> paragraph on client specific annotations means that Horde should use
>> "/vendor/kolab/h-*" for its specific features. 
>
> Citing the page:
>
>   All folders MUST be annotated with an entry
>   /vendor/kolab/folder-type containing the attribute value.shared
>   set to: <type>[.<subtype>]
>
>   For other client-specific non standardized types of folders, these
>   MUST be prefixed with "k-" for KMail, "h-" for Horde, "o-" for
>   Outlook with the Toltec Connector and "ok-" for Outlook with the
>   KONSEC Konnektor. E.g. "kolab.o-voicemail".
>
> So this h- thing is only meant for the value of the
> /vendor/kolab/folder-type annotation and can be ignored for our
> question.

As mentioned in my other mail, I misunderstood the sentence but now
that I read it again and hopefully understood it :) I would like to
use the new folder type named

 h-prefs


From wrobel at pardus.de  Wed Sep 26 08:12:44 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 26 Sep 2007 08:12:44 +0200
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <000e01c7ff35$c1f559a0$45e00ce0$@co.za> (Joon Radley's message of
	"Tue, 25 Sep 2007 07:34:30 +0200")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<20070919100516.GA1732.thomas@intevation.de>
	<002c01c7fab9$ed98db20$c8ca9160$@co.za>
	<200709250710.01493.martin.konold@erfrakon.de>
	<000e01c7ff35$c1f559a0$45e00ce0$@co.za>
Message-ID: <87wsue6jkz.fsf@home.pardus.de>

"Joon Radley" <joon at radleys.co.za> writes:

> Hi Martin,
>
>> Well, even if you cannot upload arbitrary annoations to the server it
>> does not prevent you from uploading the individual mails/objects.
> ..
>> What about an "unknown" or "other" keyword in order to allow for this.
>> It would then be the duty of the client to do the mapping e.g. using a
>> "hidden"  mail message.
>
> Then a format rule has to be created for this as some clients might display
> the "hidden" message and allow it to be deleted. 
>
> The only minor issue is that now there will be two different ways to
> identify he content type of a folder. 
>
> Should we just move completely to the hidden message solution and avoid all
> the issue with the annotation database and the fact that it seems that the
> annotation extension will not be widely adopted by other IMAP4 servers and
> only partially by Cyrus?

The draft for the METADATA extension has not seen progress in the last
five months
(https://datatracker.ietf.org/idtracker/?search_button=SEARCH&search_filename=draft-daboo-imap-annotatemore-11.txt&sub_state_id=6)
but I had the impression that it will have a better standing once it
is published as RFC. I'd wager it wouldn't be too hard to add the
extension to the newer dovecot. It seems to have nice plugin support.
At the moment I believe that the METADATA extension is no dead end.

But concerning the original Outlook issue: Does Outlook really create
new annotation types? This is the only thing that the newer Cyrus does
not permit. It does allow to use arbitrary values within
/vendor/kolab/folder-type. It just prevents you from creating
/vendor/outlook/myfancyannotation without declaring it first (this
makes also sense because the METADATA extension draft would in
principle require you to declare the new annotation type with IANA).

Cheers,

Gunnar


-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Wed Sep 26 08:16:49 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 26 Sep 2007 08:16:49 +0200
Subject: [Kolab-devel] IMAP annotation for groupware folder descriptions
In-Reply-To: <87bqbq80yw.fsf@home.pardus.de> (Gunnar Wrobel's message of "Wed,
	26 Sep 2007 07:11:51 +0200")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200709141013.55119.bernhard@intevation.de>
	<87lkb3fylt.fsf@home.pardus.de>
	<20070919070730.GB22343.thomas@intevation.de>
	<87fy1bf5x1.fsf@home.pardus.de>
	<20070919100516.GA1732.thomas@intevation.de>
	<87bqbq80yw.fsf@home.pardus.de>
Message-ID: <87fy126je6.fsf@home.pardus.de>

Gunnar Wrobel <wrobel at pardus.de> writes:

> Thomas Arendsen Hein <thomas at intevation.de> writes:
>
>> * Gunnar Wrobel <wrobel at pardus.de> [20070919 09:53]:
>>> Thomas Arendsen Hein <thomas at intevation.de> writes:
>>> > * Gunnar Wrobel <wrobel at pardus.de> [20070918 23:33]:
>>> >> If you use MySQL as the Horde backend it is trivial to support the
>>> >> description feature and there will be users using it. So I doubt that
>>> >> it will be removed. It has already existed a long time and has
>>> >> actually always been "supported" by the Kolab driver within Horde
>>> >> (even the old broken ones). The use of
>>> >> "/vendor/kolab/h-share-attr-desc" originates from the older driver
>>> >> versions.
>>> >
>>> > That's why I'd prefer /vendor/horde/something ... even if other
>>> > clients will implement it, they will be compatible with this horde
>>> > feature here.
>>> 
>>> Ah, forgot to comment on that. While the wording in the Kolab format
>>> specification at
>>> http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html#AEN157 is
>>> rather vague about this topic I assume that the intention of the
>>> paragraph on client specific annotations means that Horde should use
>>> "/vendor/kolab/h-*" for its specific features. 
>>
>> Citing the page:
>>
>>   All folders MUST be annotated with an entry
>>   /vendor/kolab/folder-type containing the attribute value.shared
>>   set to: <type>[.<subtype>]
>>
>>   For other client-specific non standardized types of folders, these
>>   MUST be prefixed with "k-" for KMail, "h-" for Horde, "o-" for
>>   Outlook with the Toltec Connector and "ok-" for Outlook with the
>>   KONSEC Konnektor. E.g. "kolab.o-voicemail".
>>
>> So this h- thing is only meant for the value of the
>> /vendor/kolab/folder-type annotation and can be ignored for our
>> question.
>
> Ah, sorry for that. Yes, I misunderstood that paragraph.
>
> So I would propose to change the corresponding attribute to
>
> /vendor/horde/description
>
> if nobody objects.

Hm, maybe I should object myself and simply check if it wouldn't make
more sense to use the "/comment" annotation described in

http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt

I will check if this is possible on the IMAP server.

Cheers,

Gunnar

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~