From joon at radleys.co.za  Fri Oct  1 10:24:40 2004
From: joon at radleys.co.za (Joon Radley)
Date: Fri, 1 Oct 2004 10:24:40 +0200
Subject: PDF version of Kolab Format
Message-ID: <20041001082439.61A5D6407@ctb-mesg1.saix.net>

Hi,

Where can I download the latest version of the Kolab Format paper in PDF
format?

Thank you

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
 



From bernhard at intevation.de  Fri Oct  1 16:59:37 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 1 Oct 2004 16:59:37 +0200
Subject: PDF version of Kolab Format
In-Reply-To: <20041001082439.61A5D6407@ctb-mesg1.saix.net>
References: <20041001082439.61A5D6407@ctb-mesg1.saix.net>
Message-ID: <200410011659.40377.bernhard@intevation.de>

On Friday 01 October 2004 10:24, Joon Radley wrote:
> Where can I download the latest version of the Kolab Format paper in PDF
> format?

Snapshots are occasionally reachable from:
http://www.kolab.org/documentation.html

The last is from 20080813,
but there was only one small chance since then:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/kolab-formats/commonfields.sgml.diff?r1=1.11&r2=1.12

I expect a bigger update tomorrow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041001/8016ca5f/attachment.p7s>

From dfaure at klaralvdalens-datakonsult.se  Fri Oct  1 17:40:11 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Fri, 1 Oct 2004 17:40:11 +0200
Subject: "Last action" fields
Message-ID: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>

On IRC today we discussed the fact that Outlook needs some "last action" fields, which we
modelled as

        <last-action>(invitation-sent, update-sent, or not present)</last-action>
        <last-action-date>(date or datetime, default not present)</start-date>
        <last-action-recipients> { <smtp-address>(string)</smtp-address> } </last-action-recipients>

<sect2><title>Last Action</title></sect2>
<para>The last action taken by the user on a given event can be "invitation-sent"
(when the initial invitation was sent), or "update-sent" when an update was sent.
The last-action-date tag stores the date and time when this last round of emails was
sent, and the list of email addresses in last-action-recipients tells who received
those mails. This makes it possible to notice, when adding a new attendee, that
we only need to send mail to that attendee.</para>
</sect2>

However this, alone, doesn't seem to me that it will be useful.
If you
A1) add a new attendee, and check the last-action-recipients list to see that
everyone else got their invitation already, OK, you can mail that attendee alone.

But if you
B1) change the location of the event, but don't send the mail yet
B2) add a new attendee, the same code as in A1 is going to send a mail
to the new attendee only. Is that OK? Shouldn't the user have a way to
flush all pending changes, i.e. inform everyone about the new location?

I'm sure there are plenty of other cases to think about (including removing and
then re-adding someone, etc.)

It seems to me that optimizations like "only mailing the new attendee" can only be
done if there is a way to compare the current revision number of the event
with the revision number that it had when the last action was done. Then we can
be sure no other change is pending.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From dfaure at klaralvdalens-datakonsult.se  Fri Oct  1 18:56:39 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Fri, 1 Oct 2004 18:56:39 +0200
Subject: "Last action" fields
In-Reply-To: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>
References: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410011856.41893.dfaure@klaralvdalens-datakonsult.se>

On Friday 01 October 2004 17:40, David Faure wrote:
> On IRC today we discussed the fact that Outlook needs some "last action" fields, which we
> modelled as
> 
>         <last-action>(invitation-sent, update-sent, or not present)</last-action>
>         <last-action-date>(date or datetime, default not present)</start-date>
>         <last-action-recipients> { <smtp-address>(string)</smtp-address> } </last-action-recipients>
> 
> <sect2><title>Last Action</title></sect2>
> <para>The last action taken by the user on a given event can be "invitation-sent"
> (when the initial invitation was sent), or "update-sent" when an update was sent.
> The last-action-date tag stores the date and time when this last round of emails was
> sent, and the list of email addresses in last-action-recipients tells who received
> those mails. This makes it possible to notice, when adding a new attendee, that
> we only need to send mail to that attendee.</para>
> </sect2>
> 
> However this, alone, doesn't seem to me that it will be useful.
> If you
> A1) add a new attendee, and check the last-action-recipients list to see that
> everyone else got their invitation already, OK, you can mail that attendee alone.
> 
> But if you
> B1) change the location of the event, but don't send the mail yet
> B2) add a new attendee, the same code as in A1 is going to send a mail
> to the new attendee only. Is that OK? Shouldn't the user have a way to
> flush all pending changes, i.e. inform everyone about the new location?

Hmm. In fact that's independent from B1.

> It seems to me that optimizations like "only mailing the new attendee" can only be
> done if there is a way to compare the current revision number of the event
> with the revision number that it had when the last action was done. Then we can
> be sure no other change is pending.
Too difficult and not worth it, let's forget about that idea.


This came from trying to understand Joon's "number of updates" field,
but he made me realize it's nonsense.
That "number of updates" is the number of times mails were sent to
update the event, but neither he nor I can see what it's used for.
(It can't be for my idea above, if the value of that number when the last
mails were sent isn't stored).
If really necessary for outlook, I can add it to the kolab format (and to
Kontact's Event object) together with the last action stuff.


Same thing for  owner-appointment-id :
Joon said: "OL creates a random 32 bit integer when an invitation is sent out. 
As far as I know this is used as part of the iTIP transactions. I will be 
storing it in the object, but we may need it later when we handle replies from attendees."
I really wonder why that is different from the event UID...
The question is, obviously: do we need to generate such a number when
the first invitation is sent from kontact?
Does anyone know if (and where) this number is used in iTIP?

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From joon at radleys.co.za  Mon Oct  4 11:57:34 2004
From: joon at radleys.co.za (Joon Radley)
Date: Mon, 4 Oct 2004 11:57:34 +0200
Subject: Attendee status
Message-ID: <20041004095732.3000D586A0@ctb-mesg6.saix.net>

Hi,

In the spec the following is said about the status in the attendee object:

"The status must be one of none, tentative, accepted, or declined.
invitation-sent only makes sense if
request-response is true. If it's false, invitation-sent should be ignored.
role is one of required, optional,
or resource."

In OL however it is possible to set the status without the
<request-response> being true. Will this be a problem to amend. 

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
 



From martin.konold at erfrakon.de  Mon Oct  4 12:12:29 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Mon, 4 Oct 2004 12:12:29 +0200
Subject: Attendee status
In-Reply-To: <20041004095732.3000D586A0@ctb-mesg6.saix.net>
References: <20041004095732.3000D586A0@ctb-mesg6.saix.net>
Message-ID: <200410041212.29547.martin.konold@erfrakon.de>

Am Montag, 4. Oktober 2004 11:57 schrieb Joon Radley:

Hi Joon,

> In OL however it is possible to set the status without the
> <request-response> being true. Will this be a problem to amend.

IMHO because there are many alternative request response channels e.g. oral 
communication via the telephone that the current OL behavior makes a lot of 
sense.

I therefore think the text of the standard shall be changed.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."
  -- Wally O'Dell - CEO of Diebold, Inc. 

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Mon Oct  4 21:15:11 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Mon, 4 Oct 2004 21:15:11 +0200
Subject: Proposal: URL attachments
In-Reply-To: <20040920135224.0919EC520@ctb-mesg6.saix.net>
References: <20040920135224.0919EC520@ctb-mesg6.saix.net>
Message-ID: <200410042115.18564.dfaure@klaralvdalens-datakonsult.se>

On Monday 20 September 2004 15:52, Joon Radley wrote:
> Hi Bo,
> 
> > When you add an attachment to an event in KOrganizer, it asks 
> > you if you want to do save this in the event, or just keep a 
> > URL around. No matter what the user chooses, we will 
> > currently override it because all attachments must be saved 
> > in the mail.
> > 
> > Could we change this to be up to the user if he wants to 
> > inline it or just link to it?
> > 
> > I propose we do these two:
> > 
> > <inline-attachment>filename</inline-attachment>
> > <link-attachment>URL</link-attachment>
> > 
> > Where the first is the current behaviour and the second 
> > contains a valid URL.
> 
> This sound fine. AFAIK Outlook does support referenced attachments, but I
> will need to spend some time on this to make sure. If not or I cannot make
> it fit, I will just preserve the tag.

OK, change made to the specification, <attachment> is gone,
<inline-attachment> and <link-attachment> replace it.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Wed Oct  6 08:27:53 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 6 Oct 2004 08:27:53 +0200
Subject: a default inbox annotation
Message-ID: <200410060827.54397.martin.konold@erfrakon.de>


Hi,

as far as I understand the Toltec Connector uses POP3 to obtain the incoming 
mails not directly IMAP. I assume that this is due to the fact that this 
allows to use the MAPI transport provider which then also allows to use the 
ical parser etc.

This leads to some minor problems when working with Kontact and Toltec on the 
same account as the effective inbox is different. 

In some way this leads to confusions with mail status flags (new/read...) and 
to duplicated mail.

I therefore propose the we define _independent_ of the IMAP INBOX a default 
Kolab inbox. The description shall happen using an IMAP annotation like 
mail.default.

Any client is then free to use whatever protocol (pop3s or IMAP) to download 
new messages but the messages then end up in the same folder finally.

What do you think?

Yours,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."
  -- Wally O'Dell - CEO of Diebold, Inc. 

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From joon at radleys.co.za  Wed Oct  6 09:35:39 2004
From: joon at radleys.co.za (Joon Radley)
Date: Wed, 6 Oct 2004 09:35:39 +0200
Subject: a default inbox annotation
In-Reply-To: <200410060827.54397.martin.konold@erfrakon.de>
Message-ID: <20041006073535.C410716F6B@ctb-mesg6.saix.net>

Hi Martin

> as far as I understand the Toltec Connector uses POP3 to obtain the 
> incoming mails not directly IMAP. I assume that this is due to the 
> fact that this allows to use the MAPI transport provider which then 
> also allows to use the ical parser etc.
> 
> This leads to some minor problems when working with Kontact and Toltec 
> on the same account as the effective inbox is different.
> 
> In some way this leads to confusions with mail status flags
> (new/read...) and to duplicated mail.
> 
> I therefore propose the we define _independent_ of the IMAP INBOX a 
> default Kolab inbox. The description shall happen using an IMAP 
> annotation like mail.default.
> 
> Any client is then free to use whatever protocol (pop3s or
> IMAP) to download new messages but the messages then end up in the 
> same folder finally.
> 
> What do you think?

Your are just saying this to make me happy. :)

In Outlook mail transport and mail storage are two separate components. The
biggest problem for us to merge the IMAP4 INBOX and the Outlook Inbox
folders are that we break the Outlook model. We have a development path to
resolve the problem, but this is complex and a lot of work. This would save
us a lot of time and pain. 

So yes I think it is a _very_ good idea, but that is only because it serves
by purposes. I would love the feedback from David and Stuart in this regard.

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



From omicron-list at mighty.co.za  Wed Oct  6 10:34:13 2004
From: omicron-list at mighty.co.za (Stuart K =?iso-8859-1?q?Bing=EB?=)
Date: Wed, 6 Oct 2004 10:34:13 +0200
Subject: a default inbox annotation
In-Reply-To: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
Message-ID: <200410061034.13685.omicron-list@mighty.co.za>

Hello Joon,

On Wednesday, 06 October 2004 09:35, Joon Radley wrote:
> > [...]
> >
> > I therefore propose the we define _independent_ of the IMAP INBOX a
> > default Kolab inbox. The description shall happen using an IMAP
> > annotation like mail.default.
> >
> > [...]
>
> Your are just saying this to make me happy. :)
>
> In Outlook mail transport and mail storage are two separate components. The
> biggest problem for us to merge the IMAP4 INBOX and the Outlook Inbox
> folders are that we break the Outlook model. We have a development path to
> resolve the problem, but this is complex and a lot of work. This would save
> us a lot of time and pain.
>
> So yes I think it is a _very_ good idea, but that is only because it serves
> by purposes. I would love the feedback from David and Stuart in this
> regard.

In the case of Horde it would require quite a bit of work to support something 
like this, as there is really nothing available currently that can handle 
what is being proposed.

That being said, it is something I (as well as the other Horde developers, in 
a more general sense) have wanted to look at; creating some form of virtual 
folder hierarchy which can be used for several purposes, such as the one 
Martin proposed here, also being able to add "search folders" (as Kontact 
does), as well as handling the groupware folders more intuitively/cleanly.

So overall I have no problem with this idea, and if it is generally beneficial 
to everyone (as it looks to be so far) then I think it's a good idea to 
persue.

Cheers,

-- 
Stuart K Bing?
 - Freelance UNIX/C++, PHP, Perl developer.

Email: omicron at mighty.co.za



From dfaure at klaralvdalens-datakonsult.se  Wed Oct  6 10:39:05 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 6 Oct 2004 10:39:05 +0200
Subject: a default inbox annotation
In-Reply-To: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
Message-ID: <200410061039.08560.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 06 October 2004 09:35, Joon Radley wrote:
> Hi Martin
> 
> > as far as I understand the Toltec Connector uses POP3 to obtain the 
> > incoming mails not directly IMAP. I assume that this is due to the 
> > fact that this allows to use the MAPI transport provider which then 
> > also allows to use the ical parser etc.
> > 
> > This leads to some minor problems when working with Kontact and Toltec 
> > on the same account as the effective inbox is different.
> > 
> > In some way this leads to confusions with mail status flags
> > (new/read...) and to duplicated mail.
> > 
> > I therefore propose the we define _independent_ of the IMAP INBOX a 
> > default Kolab inbox. The description shall happen using an IMAP 
> > annotation like mail.default.
> > 
> > Any client is then free to use whatever protocol (pop3s or
> > IMAP) to download new messages but the messages then end up in the 
> > same folder finally.
Which one? The IMAP INBOX or the kolab inbox?

> > What do you think?
> 
> Your are just saying this to make me happy. :)
> 
> In Outlook mail transport and mail storage are two separate components. The
> biggest problem for us to merge the IMAP4 INBOX and the Outlook Inbox
> folders are that we break the Outlook model. We have a development path to
> resolve the problem, but this is complex and a lot of work. This would save
> us a lot of time and pain. 
> 
> So yes I think it is a _very_ good idea, but that is only because it serves
> by purposes. I would love the feedback from David and Stuart in this regard.

Wouldn't this look *very* weird for the user? Two inboxes?

In any case I assume you're talking about letting the server-side account-creation
create that other inbox, so it wouldn't really need any change on the client side,
it would be just another imap folder that appears when syncing from the server.
So I'm not opposed, if intevation agrees with how it will look like to the user...

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Wed Oct  6 10:52:46 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 6 Oct 2004 10:52:46 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061039.08560.dfaure@klaralvdalens-datakonsult.se>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061039.08560.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410061052.47323.martin.konold@erfrakon.de>

Am Mittwoch, 6. Oktober 2004 10:39 schrieb David Faure:

Hi David,

> > > Any client is then free to use whatever protocol (pop3s or
> > > IMAP) to download new messages but the messages then end up in the
> > > same folder finally.
>
> Which one? The IMAP INBOX or the kolab inbox?

By design any retrieval of new messages from the imap server is done from the 
IMAP INBOX .

I want the destination of the messages after retrieval to be differen from the 
IMAP INBOX. This Kolab Inbox is then defined using an IMAP annotation. The 
folder name of this inbox can be arbitrary.

> Wouldn't this look *very* weird for the user? Two inboxes?

No, it would mean hiding the IMAP INBOX and only show the Kolab Inbox. 
Actually the current behavior is really confusing for many people as folder 
cannot be next to the IMAP INBOX but must be children of the IMAP INBOX. This 
problem only gets detected and synchronization time not are creation time.

The Kolab Inbox would be next to all other top level folders of the account.

> In any case I assume you're talking about letting the server-side
> account-creation create that other inbox

No.

> , so it wouldn't really need any 
> change on the client side, it would be just another imap folder that
> appears when syncing from the server. So I'm not opposed, if intevation
> agrees with how it will look like to the user...

This is not what I am considering.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."
  -- Wally O'Dell - CEO of Diebold, Inc. 

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Wed Oct  6 11:09:12 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 6 Oct 2004 11:09:12 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061052.47323.martin.konold@erfrakon.de>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061039.08560.dfaure@klaralvdalens-datakonsult.se>
	<200410061052.47323.martin.konold@erfrakon.de>
Message-ID: <200410061109.15766.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 06 October 2004 10:52, Martin Konold wrote:
> Am Mittwoch, 6. Oktober 2004 10:39 schrieb David Faure:
> 
> Hi David,
> 
> > > > Any client is then free to use whatever protocol (pop3s or
> > > > IMAP) to download new messages but the messages then end up in the
> > > > same folder finally.
> >
> > Which one? The IMAP INBOX or the kolab inbox?
> 
> By design any retrieval of new messages from the imap server is done from the 
> IMAP INBOX .
> 
> I want the destination of the messages after retrieval to be differen from the 
> IMAP INBOX. This Kolab Inbox is then defined using an IMAP annotation. The 
> folder name of this inbox can be arbitrary.

And how would the messages move from the IMAP INBOX to the Kolab Inbox?
With some client-side code??
Do we really have to recreate Outlook's abominations in Kontact? :/

> > Wouldn't this look *very* weird for the user? Two inboxes?
> 
> No, it would mean hiding the IMAP INBOX and only show the Kolab Inbox. 
> Actually the current behavior is really confusing for many people as folder 
> cannot be next to the IMAP INBOX but must be children of the IMAP INBOX. 

Wrong - you can use Prefix=/INBOX/ for this.

> The Kolab Inbox would be next to all other top level folders of the account.
> [plus: not created by server]

The Kolab Inbox *is* a real IMAP folder, right? Why wouldn't it be created by
the server then? And how can it appear next to the other toplevel folders
when not using an IMAP prefix, if cyrus doesn't support that?? 
Some client-side hack??


The kdepim people have a hard time accepting "crap solutions that make things
easier for Outlook". Kontact is not an Outlook clone, it's a general-purpose
email clients and organizer (and etc.), implementing standards.
Please come up with a solution that doesn't require to change Kontact's code
for mimicking Outlook. If this solution can be set up by simple configuration,
no problem. But if it requires hacks in Kontact...

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Wed Oct  6 11:26:56 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 6 Oct 2004 11:26:56 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061109.15766.dfaure@klaralvdalens-datakonsult.se>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061052.47323.martin.konold@erfrakon.de>
	<200410061109.15766.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410061126.56610.martin.konold@erfrakon.de>

Am Mittwoch, 6. Oktober 2004 11:09 schrieb David Faure:

Hi,

> And how would the messages move from the IMAP INBOX to the Kolab Inbox?
> With some client-side code??

Yes, this has to be done by the client. So it requires some coding.

I am aware of the fact that this means extra I/O load in the general case.

> Do we really have to recreate Outlook's abominations in Kontact? :/

Well, it is not only about Outlook but also about Kontact. Look at my office I 
have full IMAP access to my Kolab server but from some remote locations I can 
do pop3 but not IMAP. 

So currently I end up with mail duplication using only Kontact.

(The IMAP kioslaves shows the messages in the IMAP INBOX. I tend to leave 
messages in the inbox which need my attention later. When leaving the office 
and using pop3 I again get the messages downloaded to my Kmail Inbox which is 
_different_ from my Kolab INBOX. Such mail duplication is not nice)

> > No, it would mean hiding the IMAP INBOX and only show the Kolab Inbox.
> > Actually the current behavior is really confusing for many people as
> > folder cannot be next to the IMAP INBOX but must be children of the IMAP
> > INBOX.
>
> Wrong - you can use Prefix=/INBOX/ for this.

What do you mean? What shall Joe User do?

> The Kolab Inbox *is* a real IMAP folder, right?

Yes.

> Why wouldn't it be created 
> by the server then?

Because people in different cultures might choose other names. Actually I 
prefer explicit semantics (using an annotation) to implicit semantics 
(everyone is supposed to know that Kolab_Inbox is the name of the special 
Kolab folder meant to be used as the default Inbox.

> And how can it appear next to the other toplevel 
> folders when not using an IMAP prefix, if cyrus doesn't support that??
> Some client-side hack??

When you hide the real INBOX you end up with the desired behaviour.

>The kdepim people have a hard time accepting "crap solutions that make
> things easier for Outlook". Kontact is not an Outlook clone, it's a
> general-purpose email clients and organizer (and etc.), implementing
> standards.

i already regret to have used Outlook as one of the examples to benefit from 
the change. I admit that it was not wise to to do.

Actually I hope that I could show with the above example that the issue is not 
OL specific but a generic problem. (E.g. when using imap and pop3 on the same 
account)

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."
  -- Wally O'Dell - CEO of Diebold, Inc. 

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Wed Oct  6 11:41:51 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 6 Oct 2004 11:41:51 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061126.56610.martin.konold@erfrakon.de>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061109.15766.dfaure@klaralvdalens-datakonsult.se>
	<200410061126.56610.martin.konold@erfrakon.de>
Message-ID: <200410061141.54581.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 06 October 2004 11:26, Martin Konold wrote:
> Well, it is not only about Outlook but also about Kontact. Look at my office I 
> have full IMAP access to my Kolab server but from some remote locations I can 
> do pop3 but not IMAP. 
> 
> So currently I end up with mail duplication using only Kontact.
> 
> (The IMAP kioslaves shows the messages in the IMAP INBOX. I tend to leave 
> messages in the inbox which need my attention later. When leaving the office 
> and using pop3 I again get the messages downloaded to my Kmail Inbox which is 
> _different_ from my Kolab INBOX. Such mail duplication is not nice)
I see.

Assuming pop preserves the UID, I _guess_ that you wouldn't have to re-download
mail via imap that you got via pop. But will pop also be clever enough to notice which
mail you already downloaded via IMAP?

> > > No, it would mean hiding the IMAP INBOX and only show the Kolab Inbox.
> > > Actually the current behavior is really confusing for many people as
> > > folder cannot be next to the IMAP INBOX but must be children of the IMAP
> > > INBOX.
> >
> > Wrong - you can use Prefix=/INBOX/ for this.
> 
> What do you mean? What shall Joe User do?
You can try by typing "/INBOX" in the prefix lineedit of the dIMAP 
account configuration dialog box in kmail/kontact.
If this is a preferred layout for kolab2 we can make the wizard set it,
and Joe User won't have to do anything.

> Because people in different cultures might choose other names. 
Hmm, I thought the webgui knew the preferred language. OK, whatever.

> Actually I prefer explicit semantics (using an annotation) to implicit semantics 
Sure, never said the contrary.

OK, I understand the idea now - basically treating IMAP INBOX like a pop account:
as a way to download mail, but then it arrives into another folder.
*However* this is going to be awful for the user, because all the messages that
you download from your IMAP INBOX will have to be re-uploaded on the next sync,
since they are now in another folder!

Also, I doubt that it's a good idea to make this kind of fundamental change at this point.
Aren't we late already in the project? How will we ever get to the end of it in time,
if new requirements pop up every week?
Downloading mail via both POP and IMAP might be an interesting problem to solve,
but it isn't part of the proko2 specifications.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From matt at fruitsalad.org  Wed Oct  6 11:52:11 2004
From: matt at fruitsalad.org (Matt Douhan)
Date: Wed, 6 Oct 2004 11:52:11 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061126.56610.martin.konold@erfrakon.de>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061109.15766.dfaure@klaralvdalens-datakonsult.se>
	<200410061126.56610.martin.konold@erfrakon.de>
Message-ID: <200410061152.11365.matt@fruitsalad.org>

On Wednesday 06 October 2004 11.26, Martin Konold wrote:
> Well, it is not only about Outlook but also about Kontact. Look at my
> office I have full IMAP access to my Kolab server but from some remote
> locations I can do pop3 but not IMAP.
>
> So currently I end up with mail duplication using only Kontact.
>

I agree with Martin on this, I have the exact same setup as he is describing, 
with the same POP3 IMAP issues ( not really issues but *features*)

Also a lot of our employees use it as well, this could be sorted with ssh 
tunnels to the IMAP server but I am unable to find a precommand in KMail for 
IMAP but thats a different story.

rgds

Matt



From bernhard at intevation.de  Wed Oct  6 11:56:12 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 6 Oct 2004 11:56:12 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061141.54581.dfaure@klaralvdalens-datakonsult.se>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061126.56610.martin.konold@erfrakon.de>
	<200410061141.54581.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410061156.16792.bernhard@intevation.de>

On Wednesday 06 October 2004 11:41, David Faure wrote:
> On Wednesday 06 October 2004 11:26, Martin Konold wrote:

The discussion of the following problem and suggestion should
be moved to kolab-devel and to kde-pim or kmail-devel I would say.
Because this is not directly related to the format, but to a general problem
with how to handle incoming mail and several ways to get them.

> > (The IMAP kioslaves shows the messages in the IMAP INBOX. I tend to leave
> > messages in the inbox which need my attention later. When leaving the
> > office and using pop3 I again get the messages downloaded to my Kmail
> > Inbox which is _different_ from my Kolab INBOX. Such mail duplication is
> > not nice)

> OK, I understand the idea now - basically treating IMAP INBOX like a pop
> account: as a way to download mail, but then it arrives into another
> folder. *However* this is going to be awful for the user, because all the
> messages that you download from your IMAP INBOX will have to be re-uploaded
> on the next sync, since they are now in another folder!

(I think Martin already wrote that he is aware of this.)

> Also, I doubt that it's a good idea to make this kind of fundamental change
> at this point. Aren't we late already in the project? How will we ever get
> to the end of it in time, if new requirements pop up every week?
> Downloading mail via both POP and IMAP might be an interesting problem to
> solve, but it isn't part of the proko2 specifications.

Proko2 needs a funcational windows client, 
thus for windows a solution is needed.
If this change would solve general KMail problems
then it is desirable for Proko2, because it helps Joon on the windows side.

Martin: Please take this to the KDE people, 
independent from the format and Outlook.

Bernhard



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041006/d5d7b731/attachment.p7s>

From martin.konold at erfrakon.de  Wed Oct  6 12:19:25 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 6 Oct 2004 12:19:25 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061141.54581.dfaure@klaralvdalens-datakonsult.se>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061126.56610.martin.konold@erfrakon.de>
	<200410061141.54581.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410061219.26238.martin.konold@erfrakon.de>

Am Mittwoch, 6. Oktober 2004 11:41 schrieb David Faure:

Hi David,

> Assuming pop preserves the UID, I _guess_ that you wouldn't have to
> re-download mail via imap that you got via pop. But will pop also be clever
> enough to notice which mail you already downloaded via IMAP?

Yes, pop after imap is the problem. pop is not smart enough in this respect.

> folder. *However* this is going to be awful for the user, because all the
> messages that you download from your IMAP INBOX will have to be re-uploaded
> on the next sync, since they are now in another folder!

Yes, this is the major disadvantage for the user. A future IMAP extension 
allowing to move messages on the server would help though.

> Downloading mail via both POP and IMAP might be an interesting problem to
> solve, but it isn't part of the proko2 specifications.

Yes, but I am discussing here the common specifications and as Joon could 
really benefit from this change in the spec I think it is really worht to be 
considered to be put in the specs.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."
  -- Wally O'Dell - CEO of Diebold, Inc. 

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From martin.konold at erfrakon.de  Wed Oct  6 12:20:58 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 6 Oct 2004 12:20:58 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061152.11365.matt@fruitsalad.org>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061126.56610.martin.konold@erfrakon.de>
	<200410061152.11365.matt@fruitsalad.org>
Message-ID: <200410061220.58990.martin.konold@erfrakon.de>

Am Mittwoch, 6. Oktober 2004 11:52 schrieb Matt Douhan:

Hi,

> tunnels to the IMAP server but I am unable to find a precommand in KMail
> for IMAP but thats a different story.

Actually this is also the reason why I triggered the issue.

David: How much effort would it be to add the precommand feature also to dIMAP 
connections. Basically this is also good for coherence with regards to the 
UI.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."
  -- Wally O'Dell - CEO of Diebold, Inc. 

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Wed Oct  6 12:57:02 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 6 Oct 2004 12:57:02 +0200
Subject: a default inbox annotation
In-Reply-To: <200410061220.58990.martin.konold@erfrakon.de>
References: <20041006073535.C410716F6B@ctb-mesg6.saix.net>
	<200410061152.11365.matt@fruitsalad.org>
	<200410061220.58990.martin.konold@erfrakon.de>
Message-ID: <200410061259.41811.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 06 October 2004 12:20, Martin Konold wrote:
> Am Mittwoch, 6. Oktober 2004 11:52 schrieb Matt Douhan:
> 
> Hi,
> 
> > tunnels to the IMAP server but I am unable to find a precommand in KMail
> > for IMAP but thats a different story.
> 
> Actually this is also the reason why I triggered the issue.
> 
> David: How much effort would it be to add the precommand feature also to dIMAP 
> connections.

Probably much less work than the rest of the stuff we're talking about here :) 
Till, do you know a more precise answer to that question?

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
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: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20041006/081fbe16/attachment.sig>

From bernhard at intevation.de  Wed Oct  6 15:34:28 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 6 Oct 2004 15:34:28 +0200
Subject: Alarm setting?
In-Reply-To: <200409221637.28222.reinhold@kainhofer.com>
References: <200409171842.12205.reinhold@kainhofer.com>
	<200409221608.33191.bernhard@intevation.de>
	<200409221637.28222.reinhold@kainhofer.com>
Message-ID: <200410061534.31993.bernhard@intevation.de>

On Wednesday 22 September 2004 16:37, Reinhold Kainhofer wrote:
> On Wednesday,  22. September 2004 16:08, Bernhard Reiter wrote:
> > On Wednesday 22 September 2004 13:50, Reinhold Kainhofer wrote:

> > Our idea with the Kolab2 format is to first support
> > the most common way,
>
> Okay, I just wanted to tell you about my plans for korganizer. KOrganizer
> is already at the second step: It already has all the functionality for the
> most common way of calendaring.

I tend to disagree, because it cannot be used in a groupware
setup with several people.  (This is not a topic for kolab-format,
I am thinking unique id problems, the time zone issue,
the identify problems and the difficulties with inviting and directly
writing calendars.)

> > Do not get me wrong at this: I am in favour of trying to add more
> > capabilites, but in terms of avaiable Free Software groupware solutions,
> > it seems to be the second step before the first.
>
> Okay. In terms of available Free Software calendar user agents, we are at
> the second step, and now I'm thinking about more capabilities for
> korganizer.

As I wrote above: I tend to disagree,
but this is certainly a matter of perspective.
For some users a gropware funcationality with remote resources
is not that important, for others it is crucial.

> So your suggestion is to just remove all functionality that might not work
> with a shared folder? or with different groups of people accessing it?

No, I hope that we can make that configurable if we do not agree
that it might be too much funcationality.
(Because in some cases too many features are a step back.
for the usability)

> > I do not see a problem making attachments like email attachements
> > to work reliably cross plattform. They are just binary blobs with a
> > content-type.
>
> I'm not talking about email attachments. I'm talking about attachments to
> events and todos. You can attach any URI (e.g. path to a local file, a URL
> to some web page, or a link to a mail in kmail) to incidences in
> KOrganizer. Of course, the local pathes and kmail uids will be highly
> platform-dependent.

The reference to a local file system is something that I believe is not
good and should be avoided in all groupware systems.
(Thus I would suggest to not add support in the format for it.)
As for URL references and attachements to events and todos:
I was talking about them, because
in the Kolab2 XML storage format those are email attachments
(which get referenced in the XML).

> The RFC is not meant as a guidline what a calendaring app MUST implement,
> but rather tries to be a complete specification of all the things a
> calendaring app MIGHT ever want to implement.

This is a drawback, because you can never be sure if
the other client can do what you can do.

> Your Kolab specification is just the other way round: It defines the things
> that a kolab client MUST implement, which is only the most common features.
> If an application supports additional features, well, it's basically on its
> own.

That is not  completely true as we preserve unknown tags.
In general I believe the approach is excately what is needed
from a 3rd system and iCalendar feels like a typical 2nd system format.

> > > These issues ARE demanded by the users:
> > > Multiple alarms: bug #16493 (one of our oldest wishes)
> > > email reminder: bug #50292
> > > reminders relative to the end: bug #82105
> >
> > I read through the issues now.
> > My estimation still holds that this is not the most important thing
> > and other stuff is more important, especially in a real groupware setup.
>
> For kolab2 that might be true.
> For KOrganizer as a calendar user agent, these are my priorities.

I am not to set your priorities, but as written above I believe that you
are fostering a small user base instead of a bigger one.
To reach corporate users multiple alarms are not
the stumbling block today.

> > > And in case you didn't notice: Sounds and procedure alarm have already
> > > been supported by korganizer for some years...
> >
> > I saw that, but I never used it.
> > How many different alarm sound do you have set?
>
> I don't have any, but then I don't use alarms at all, anyway.

I never used sound here, for me that is a sign that this is not
that required in a even fancier version.

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041006/5503a181/attachment.p7s>

From reinhold at kainhofer.com  Wed Oct  6 16:05:30 2004
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed, 6 Oct 2004 16:05:30 +0200
Subject: Alarm setting?
In-Reply-To: <200410061534.31993.bernhard@intevation.de>
References: <200409171842.12205.reinhold@kainhofer.com>
	<200409221637.28222.reinhold@kainhofer.com>
	<200410061534.31993.bernhard@intevation.de>
Message-ID: <200410061605.32986.reinhold@kainhofer.com>

On Wednesday 06 October 2004 15:34, Bernhard Reiter wrote:
> I tend to disagree, because it cannot be used in a groupware
> setup with several people.  (This is not a topic for kolab-format,
> I am thinking unique id problems, the time zone issue,

Yes, the time zone issue is a general KOrg problem, not only for groupware.

> the identify problems 

Which identify problems?

> and the difficulties with inviting and directly 
> writing calendars.)

Which problems are these?

> > > I do not see a problem making attachments like email attachements
> > > to work reliably cross plattform. They are just binary blobs with a
> > > content-type.
> >
> > I'm not talking about email attachments. I'm talking about attachments to
> > events and todos. You can attach any URI (e.g. path to a local file, a
> > URL to some web page, or a link to a mail in kmail) to incidences in
> > KOrganizer. Of course, the local pathes and kmail uids will be highly
> > platform-dependent.
>
> The reference to a local file system is something that I believe is not
> good and should be avoided in all groupware systems.

So how do you want to handle them? Always attaching the whole file to the 
event. Now, add a few images, and you'll end up with a >10MB calendar...

Also remember, KOrganizer is not a synonym for "Groupware system". Some people 
also use korganizer as their "project" management system, where they put the 
references to all the documents needed into the events' attachments, to have 
easy access to them. 

> > The RFC is not meant as a guidline what a calendaring app MUST implement,
> > but rather tries to be a complete specification of all the things a
> > calendaring app MIGHT ever want to implement.
>
> This is a drawback, because you can never be sure if
> the other client can do what you can do.

So what? All information needs to be preserved, anyway. 
Basically, you are saying, that korganizer mustn't support more than any other 
calendaring application does support?
Just because Outlook and Evolution don't support hierarchical to-do lists, 
that doesn't mean korganizer can't support them. The rfc give a standard for 
this, and if one application does not support relations, okay, fine, but 
others can make use of it.

> > Your Kolab specification is just the other way round: It defines the
> > things that a kolab client MUST implement, which is only the most common
> > features. If an application supports additional features, well, it's
> > basically on its own.
>
> That is not  completely true as we preserve unknown tags.
> In general I believe the approach is excately what is needed
> from a 3rd system and iCalendar feels like a typical 2nd system format.

What's a 3rd system and a 2nd system?
iCalendar also specifies that unknown tags MUST be preserved (emphasis copied 
from the rfc).


Reinhold
-------------- 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/20041006/c41e4553/attachment.sig>

From bernhard at intevation.de  Thu Oct  7 12:54:46 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 7 Oct 2004 12:54:46 +0200
Subject: Which Korganizer features are important for Groupware?(was: Alarm
	setting?)
In-Reply-To: <200410061605.32986.reinhold@kainhofer.com>
References: <200409171842.12205.reinhold@kainhofer.com>
	<200410061534.31993.bernhard@intevation.de>
	<200410061605.32986.reinhold@kainhofer.com>
Message-ID: <200410071254.49573.bernhard@intevation.de>

[Can we take this to kolab-devel?
Reply-to set. (KMail cannot easily set Mailfollow-up.)]

On Wednesday 06 October 2004 16:05, Reinhold Kainhofer wrote:
> On Wednesday 06 October 2004 15:34, Bernhard Reiter wrote:
> > I tend to disagree, because it cannot be used in a groupware
> > setup with several people.  (This is not a topic for kolab-format,
> > I am thinking unique id problems, the time zone issue,
>
> Yes, the time zone issue is a general KOrg problem, not only for groupware.
>
> > the identify problems
> Which identify problems?

Bo and David will have the details.
The problem is when you act as a secretary for somebody else
and have write access to several groupware calendar folders.

> > and the difficulties with inviting and directly
> > writing calendars.)
>
> Which problems are these?

Details are also in the tracker, e.g. you cannot load two UIDs,
which appears when you have access to the calendar folder
of your friend which you just invited by email.

> > > > I do not see a problem making attachments like email attachements
> > > > to work reliably cross plattform. They are just binary blobs with a
> > > > content-type.
> > >
> > > I'm not talking about email attachments. I'm talking about attachments
> > > to events and todos. You can attach any URI (e.g. path to a local file,
> > > a URL to some web page, or a link to a mail in kmail) to incidences in
> > > KOrganizer. Of course, the local pathes and kmail uids will be highly
> > > platform-dependent.
> >
> > The reference to a local file system is something that I believe is not
> > good and should be avoided in all groupware systems.
>
> So how do you want to handle them? Always attaching the whole file to the
> event. Now, add a few images, and you'll end up with a >10MB calendar...

For now I want to do this and thinking about real document management
systems in a distributed world with several servers is a hard problem.
Someone could think of URIs or so.

> Also remember, KOrganizer is not a synonym for "Groupware system". Some
> people also use korganizer as their "project" management system, where they
> put the references to all the documents needed into the events'
> attachments, to have easy access to them.

This is just what I am saying: KOrganizer is not ready to be part of
a real "Groupware solution" and in making it ready we also think
of what it should be and how it can be that.

> > > The RFC is not meant as a guidline what a calendaring app MUST
> > > implement, but rather tries to be a complete specification of all the
> > > things a calendaring app MIGHT ever want to implement.
> >
> > This is a drawback, because you can never be sure if
> > the other client can do what you can do.
>
> So what? All information needs to be preserved, anyway.

But not presented and dealt with. 
In saying this is the information you need to deal with at least
to be compatible, we actually allow a practical Groupware storage
format for the first time.

> Basically, you are saying, that korganizer mustn't support more than any
> other calendaring application does support?
> Just because Outlook and Evolution don't support hierarchical to-do lists,
> that doesn't mean korganizer can't support them. The rfc give a standard
> for this, and if one application does not support relations, okay, fine,
> but others can make use of it.

No you seem to missunderstand me here.
I have no problem with KOrganizer begin able to do anything,
but I also want Korganizer to be part of a practical groupware solution.
We need to approach this state somehow and yes for this to do
we need to take two clients and try to find a common set 
of groupware funcationality that users already know
and then start with that as a practical approach.

> > > Your Kolab specification is just the other way round: It defines the
> > > things that a kolab client MUST implement, which is only the most
> > > common features. If an application supports additional features, well,
> > > it's basically on its own.
> >
> > That is not  completely true as we preserve unknown tags.
> > In general I believe the approach is excately what is needed
> > from a 3rd system and iCalendar feels like a typical 2nd system format.
>
> What's a 3rd system and a 2nd system?

http://en.wikipedia.org/wiki/Second-system_effect

Best,
    Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041007/6d14b3b8/attachment.p7s>

From bernhard at intevation.de  Thu Oct  7 15:08:19 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 7 Oct 2004 15:08:19 +0200
Subject: "Last action" fields
In-Reply-To: <200410011856.41893.dfaure@klaralvdalens-datakonsult.se>
References: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>
	<200410011856.41893.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410071508.22833.bernhard@intevation.de>

We do not have last-action in the specs yet,
so let us make some progress here.

Please all  says again if we should add this
to the spec and you agree with it.
Then David can add it.


On Friday 01 October 2004 18:56, David Faure wrote:
> On Friday 01 October 2004 17:40, David Faure wrote:
> > On IRC today we discussed the fact that Outlook needs some "last action"
> > fields, which we modelled as
> >
> >         <last-action>(invitation-sent, update-sent, or not
> > present)</last-action> <last-action-date>(date or datetime, default not
> > present)</start-date> <last-action-recipients> {
> > <smtp-address>(string)</smtp-address> } </last-action-recipients>
> >
> > <sect2><title>Last Action</title></sect2>
> > <para>The last action taken by the user on a given event can be
> > "invitation-sent" (when the initial invitation was sent), or
> > "update-sent" when an update was sent. The last-action-date tag stores
> > the date and time when this last round of emails was sent, and the list
> > of email addresses in last-action-recipients tells who received those
> > mails. This makes it possible to notice, when adding a new attendee, that
> > we only need to send mail to that attendee.</para>
> > </sect2>

I was immedeately thinking about doing the last action per recipient,
but it well might be that this modelling is enough.

> > However this, alone, doesn't seem to me that it will be useful.
> > If you
> > A1) add a new attendee, and check the last-action-recipients list to see
> > that everyone else got their invitation already, OK, you can mail that
> > attendee alone.

Note that Outlook will ask the user for this case and give a 
tripple choice: 
	Mail on the the new attendees.
	Mail all 
	Do not mail the update.

> > But if you
> > B1) change the location of the event, but don't send the mail yet
> > B2) add a new attendee, the same code as in A1 is going to send a mail
> > to the new attendee only. Is that OK? Shouldn't the user have a way to
> > flush all pending changes, i.e. inform everyone about the new location?
>
> Hmm. In fact that's independent from B1.

An update all button seems useful, I am currently unsure if outlook has one.

> > It seems to me that optimizations like "only mailing the new attendee"
> > can only be done if there is a way to compare the current revision number
> > of the event with the revision number that it had when the last action
> > was done. Then we can be sure no other change is pending.
>
> Too difficult and not worth it, let's forget about that idea.

As explained before we cannot be sure to see all revisions of
an event, because other clients might work on it.
So I could imagine a comparision to the change date and the last-action-date
that probably is a good hint.

> This came from trying to understand Joon's "number of updates" field,
> but he made me realize it's nonsense.
> That "number of updates" is the number of times mails were sent to
> update the event, but neither he nor I can see what it's used for.
> (It can't be for my idea above, if the value of that number when the last
> mails were sent isn't stored).
> If really necessary for outlook, I can add it to the kolab format (and to
> Kontact's Event object) together with the last action stuff.

Joon: Is it okay to leave that out from the spec for now until
we find out what it is used for?
(or did we already find out in the meantime?)


> Same thing for  owner-appointment-id :
> Joon said: "OL creates a random 32 bit integer when an invitation is sent
> out. As far as I know this is used as part of the iTIP transactions. I will
> be storing it in the object, but we may need it later when we handle
> replies from attendees." I really wonder why that is different from the
> event UID...
> The question is, obviously: do we need to generate such a number when
> the first invitation is sent from kontact?
> Does anyone know if (and where) this number is used in iTIP?

No idea, maybe you can ask someone at kolab-devel and kdepim
if they know more?

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041007/b045d7b2/attachment.p7s>

From bernhard at intevation.de  Thu Oct  7 16:29:12 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 7 Oct 2004 16:29:12 +0200
Subject: Text Remarks
Message-ID: <200410071629.16078.bernhard@intevation.de>

In the train on the 4th I could browse the full kolab-format spec.
Here are a couple of remarks, somebody who implements
this should be the keeper of the scrolls. (David?)

section 1.2. XML format description:
	<type>  
misses a "version" attribute which is
there in later examples like Chapter 5. Format Of Notes.
Proposed fix: add <type version=""> and a description...


2.1. IMAP requirements

It says:
     The INBOX will have the IMAP resource subfolders (like we do today in the clients),
This seems to be not very precise, especially the part in brackets.
Proposed fix: elaborate a bit and/or reference another document

later in the same section:  
    there should be prefixed with k for KMail, h for Horde and o for Outlook

Should this be "k-" and "h-" or so, because this is how it is done in the 
example?


later:
    This is all quite restricted, but this is the only way Outlook can do it...
This does not seem to be a good and correct statement to make,
because both client worlds clash here, not this is not the fault of one alone.
Proposed fix: Remove the paragraph.


4.1. Common In All Types
uid
	shouldn't we describe further what could be an UID,
string would also allow newlines and spaces and we probably do not
want them in the UID. Or do we?

Proposed fix: Describe more rules for "uid", beyond string.

Later:
    The categories is a comma separated list.
What did that sentence want to say?
Proposed fix: Rephrase.

4.2. Common In Tasks and Events
It says:
     In the case of a all days event (floating event) ...
(Beside the typo "a" -> "an") how to we distinquish 
between a "floating" and a 24 h event?

4.2.1. Recurrence

The strings "Daily", "Weekly" habe a capital letter, but they 
are probably meant lower case. Tag names are case sensitive
says 1.2, but does this also hold for the list of possible attribute values
and the attribute names itself?
Proposed fix: Add statement about case sensiticity to 1.2 and 
write Daily as "daily" if it was meant lower case.
Also with Weekly, Montyly and Yearly.

4.2.3 Examples

It might be good to have one example with attendees,
there is none.

5. Format of Notes
There is no reference to 4.1 Common In all Types.
This is the same with 6., 7., 8. and  9.
If we have a common field section, there is no need to specify
it several times. 

Also <product> seems to be missing from 5.6.7.8. 9.
which is in 4.1.

6. Format Of Contacts
beside the issues mentioned under 5.
It would be interesting to add how many addresses of which
type need to be displayed at least to the user to be compliant.


8. Format Of Events
This seems to be a largely duplication of Chaper 4.2.

We also need to specify somewhere how a categories
of "personal" will be handled as this would be interesting
for freebusy list creation. So maybe we need a few fixed
categories that can get translated.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041007/3a61b00a/attachment.p7s>

From bernhard at intevation.de  Thu Oct  7 16:49:42 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 7 Oct 2004 16:49:42 +0200
Subject: PDF version of Kolab Format
In-Reply-To: <200410011659.40377.bernhard@intevation.de>
References: <20041001082439.61A5D6407@ctb-mesg1.saix.net>
	<200410011659.40377.bernhard@intevation.de>
Message-ID: <200410071649.45418.bernhard@intevation.de>

On Friday 01 October 2004 16:59, Bernhard Reiter wrote:
> On Friday 01 October 2004 10:24, Joon Radley wrote:
> > Where can I download the latest version of the Kolab Format paper in PDF
> > format?
>
> Snapshots are occasionally reachable from:
> http://www.kolab.org/documentation.html

I have added a new one to the webpage.
The link will soon go to:
http://kolab.org/doc/kolabformat-draft-cvs20041007.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041007/e8a0f007/attachment.p7s>

From reinhold at kainhofer.com  Thu Oct  7 17:26:18 2004
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu, 7 Oct 2004 17:26:18 +0200
Subject: PDF version of Kolab Format
In-Reply-To: <200410071649.45418.bernhard@intevation.de>
References: <20041001082439.61A5D6407@ctb-mesg1.saix.net>
	<200410011659.40377.bernhard@intevation.de>
	<200410071649.45418.bernhard@intevation.de>
Message-ID: <200410071726.20489.reinhold@kainhofer.com>

On Thursday 07 October 2004 16:49, Bernhard Reiter wrote:
> I have added a new one to the webpage.

I just saw that the tasks don't have any entry for the completion date (just 
for the completion percentage). Is this on purpose?

Reinhold
-------------- 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/20041007/4e0e99dd/attachment.sig>

From dfaure at klaralvdalens-datakonsult.se  Thu Oct  7 17:28:02 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Thu, 7 Oct 2004 17:28:02 +0200
Subject: "Last action" fields
In-Reply-To: <200410071508.22833.bernhard@intevation.de>
References: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>
	<200410011856.41893.dfaure@klaralvdalens-datakonsult.se>
	<200410071508.22833.bernhard@intevation.de>
Message-ID: <200410071728.03709.dfaure@klaralvdalens-datakonsult.se>

On Thursday 07 October 2004 15:08, Bernhard Reiter wrote:
> We do not have last-action in the specs yet,
> so let us make some progress here.
> 
> Please all  says again if we should add this
> to the spec and you agree with it.
> Then David can add it.
I'm fine with adding it and ignoring it in Kontact, but that's probably not
what we want for full interoperability.

The real question is whether we need to change korganizer's invitation handling
or not. But I don't know enough about korganizer's invitation handling AND about
Outlook's invitation handling to provide any useful input.

> I was immedeately thinking about doing the last action per recipient,
> but it well might be that this modelling is enough.
This is even more detailed, more than Joon requested, so I'm guessing
Outlook (or the connector) can't do that?

> Note that Outlook will ask the user for this case and give a 
> triple choice: 
>  Mail on the the new attendees.
>  Mail all 
>  Do not mail the update.
OK.

> As explained before we cannot be sure to see all revisions of
> an event, because other clients might work on it.
> So I could imagine a comparision to the change date and the last-action-date
> that probably is a good hint.
Well, but we can't just make up algorithms as we want here, if this
is built into Outlook, can we?

> > The question is, obviously: do we need to generate such a number when
> > the first invitation is sent from kontact?
> > Does anyone know if (and where) this number is used in iTIP?
> 
> No idea, maybe you can ask someone at kolab-devel and kdepim
> if they know more?

Asking a question about outlook's owner-appointment-id on kdepim?
Doesn't look like the right place to me.
I'm not on kolab-devel at the moment; should I be? (we really have too many lists...)

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Thu Oct  7 17:40:02 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Thu, 7 Oct 2004 17:40:02 +0200
Subject: PDF version of Kolab Format
In-Reply-To: <200410071649.45418.bernhard@intevation.de>
References: <20041001082439.61A5D6407@ctb-mesg1.saix.net>
	<200410011659.40377.bernhard@intevation.de>
	<200410071649.45418.bernhard@intevation.de>
Message-ID: <200410071740.02481.martin.konold@erfrakon.de>

Am Donnerstag, 7. Oktober 2004 16:49 schrieb Bernhard Reiter:

Hi,

> The link will soon go to:
> http://kolab.org/doc/kolabformat-draft-cvs20041007.pdf

We already have the news about the draft since Aug. 12th but the link is still 
missing :-(

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."
  -- Wally O'Dell - CEO of Diebold, Inc. 

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From reinhold at kainhofer.com  Thu Oct  7 18:02:39 2004
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu, 7 Oct 2004 18:02:39 +0200
Subject: "Last action" fields
In-Reply-To: <200410071728.03709.dfaure@klaralvdalens-datakonsult.se>
References: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>
	<200410071508.22833.bernhard@intevation.de>
	<200410071728.03709.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410071802.41631.reinhold@kainhofer.com>

On Thursday 07 October 2004 17:28, David Faure wrote:
> On Thursday 07 October 2004 15:08, Bernhard Reiter wrote:
> > We do not have last-action in the specs yet,
> > so let us make some progress here.
> >
> > Please all  says again if we should add this
> > to the spec and you agree with it.
> > Then David can add it.
>
> I'm fine with adding it and ignoring it in Kontact, but that's probably not
> what we want for full interoperability.
>
> The real question is whether we need to change korganizer's invitation
> handling or not. 

KOrganizer's old invitation handling mechanism still has something like that. 
It only stores the last action in it's own config file, rather than in the 
calendar (as it should be). Actually, this has cause me some headaches 
already, because it prevented cancel messages being sent to removed attendees 
(since the invitation was never sent out by the old groupware code, but by 
the new, but the old one assumed it'sthe only groupware code in 
korganizer...)
The new code (which is used if the "Use groupware communication" checkbox is 
enabled), never had something like that.

> > Note that Outlook will ask the user for this case and give a
> > triple choice:
> >  Mail on the the new attendees.
> >  Mail all
> >  Do not mail the update.
>
> OK.

KOrg only asks "Mail" or "dont mail" when adding attendees. When removing 
attendees, korg asks if cancel messages should be sent to the removed 
attendees, and then it asks if the changes should be sent to the other 
(non-removed) attendees.

> > As explained before we cannot be sure to see all revisions of
> > an event, because other clients might work on it.
> > So I could imagine a comparision to the change date and the
> > last-action-date that probably is a good hint.
>
> Well, but we can't just make up algorithms as we want here, if this
> is built into Outlook, can we?

The icalendar spec is quite clear on this issue: The event with the higher 
revision number always wins. Changes can (shall) only be made by the 
organizer, anyway. So, basically, all icalendar-based apps will probably just 
look at the revision.


Reinhold
-------------- 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/20041007/c3cf2046/attachment.sig>

From dfaure at klaralvdalens-datakonsult.se  Thu Oct  7 20:09:44 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Thu, 7 Oct 2004 20:09:44 +0200
Subject: Text Remarks
In-Reply-To: <200410071629.16078.bernhard@intevation.de>
References: <200410071629.16078.bernhard@intevation.de>
Message-ID: <200410072009.47720.dfaure@klaralvdalens-datakonsult.se>

On Thursday 07 October 2004 16:29, Bernhard Reiter wrote:
> In the train on the 4th I could browse the full kolab-format spec.
> Here are a couple of remarks, somebody who implements
> this should be the keeper of the scrolls. (David?)
Yes.

> section 1.2. Proposed fix: add <type version=""> and a description...
Done.

> 2.1. IMAP requirements
> 
> It says:
>      The INBOX will have the IMAP resource subfolders (like we do today in the clients),
> This seems to be not very precise, especially the part in brackets.
> Proposed fix: elaborate a bit and/or reference another document
Done.

> Should this be "k-" and "h-" or so, because this is how it is done in the 
> example?
Done.

> Proposed fix: Remove the paragraph.
Removed.

> 4.1. Common In All Types
> uid
>  shouldn't we describe further what could be an UID,
> string would also allow newlines and spaces and we probably do not
> want them in the UID. Or do we?
> Proposed fix: Describe more rules for "uid", beyond string.
OK, 7-bit would avoid causing encoding problems, but other than that I 
see no reason for further restrictions (we just store the uid as a string....).
Joon: do you have restrictions on the characters used in the uid? I vaguely
remember a discussion about that (on irc) but I don't remember the outcome.

Anyway, Toltech and Kontact seem to stick to [a-zA-Z0-9.-] currently.

> Later:
>     The categories is a comma separated list.
> What did that sentence want to say?
> Proposed fix: Rephrase.
It looks clear to me: <categories> contains a comma-separated list of categories.
(is that way better than the way in the document, because of "the categories is"?)

> 4.2. Common In Tasks and Events
> It says:
>      In the case of a all days event (floating event) ...
> how to we distinquish between a "floating" and a 24 h event?
This seems clear to me too: floating events have no time information,
a 24h event would have  time information, as the spec says.

> 4.2.1. Recurrence
> 
> The strings "Daily", "Weekly" habe a capital letter, but they 
> are probably meant lower case. Tag names are case sensitive
> says 1.2, but does this also hold for the list of possible attribute values
> and the attribute names itself?
> Proposed fix: Add statement about case sensiticity to 1.2 and 
Done.

> write Daily as "daily" if it was meant lower case.
> Also with Weekly, Montyly and Yearly.
Fixed.

> 4.2.3 Examples
> 
> It might be good to have one example with attendees,
> there is none.

I disagree - this is the examples section that details the various recurrence
rules. All other sections do not have actual examples with fake data,
since the beginning of every section *is* a kind of example already.

We would end up with even more duplication if we repeated the whole
structure of an e.g. event with all the fields yet again.

[For more examples with fake data there is the validation/tests directory]

> 5. Format of Notes
> There is no reference to 4.1 Common In all Types.
> This is the same with 6., 7., 8. and  9.
Added a link in the description.

> If we have a common field section, there is no need to specify
> it several times. 
You mean we shouldn't have the fields? Well the whole idea was (AFAICS)
to have self-contained "examples" of how an event looks like.
It's not practical if, in order to look for the fields of an event, you have to consult
3 sections. Hence the repetition.

> Also <product> seems to be missing from 5.6.7.8. 9.
> which is in 4.1.
You mean product-id I assume? Added.

> 6. Format Of Contacts
> beside the issues mentioned under 5.
> It would be interesting to add how many addresses of which
> type need to be displayed at least to the user to be compliant.
"type" is home or business or other. Do you mean the spec should
say "Clients should be able to display at least one address of each type"?
If you want, but I thought clients supported more than one address of each
type anyway - for sure kontact loads and displayed all addresses.
Unlike the phone stuff, this isn't a "one of each kind" type of data,
it's a list of addresses, with a flag (the type) on each.
Joon: is that different in outlook?

> 8. Format Of Events
> This seems to be a largely duplication of Chaper 4.2.
Well, yes, but this is in order to provide a full "example" of how an event looks like.
You requested examples, didn't you? :)

> We also need to specify somewhere how a categories
> of "personal" will be handled as this would be interesting
> for freebusy list creation. So maybe we need a few fixed
> categories that can get translated.
OK this is something I know nothing about - was it discussed already?
<categories> is pretty generic in the format currently. Do you really want
to abuse that one, or shouldn't this rather be done in a separate field?
What's the relation to freebusy-list-creation?

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From bernhard at intevation.de  Fri Oct  8 16:30:26 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 8 Oct 2004 16:30:26 +0200
Subject: PDF version of Kolab Format
In-Reply-To: <200410071740.02481.martin.konold@erfrakon.de>
References: <20041001082439.61A5D6407@ctb-mesg1.saix.net>
	<200410071649.45418.bernhard@intevation.de>
	<200410071740.02481.martin.konold@erfrakon.de>
Message-ID: <200410081630.29063.bernhard@intevation.de>

On Thursday 07 October 2004 17:40, Martin Konold wrote:
> Am Donnerstag, 7. Oktober 2004 16:49 schrieb Bernhard Reiter:

> > The link will soon go to:
> > http://kolab.org/doc/kolabformat-draft-cvs20041007.pdf
>
> We already have the news about the draft since Aug. 12th but the link is
> still missing :-(

No the link was there all the time from the documentation section
http://www.kolab.org/documentation.html

That was on purpose, because after the news I added two more version
to the documentation section and that would have invalidated the news link.
(As has happened before.)
There are several solution to the problem. For now I added a link
to the documentation section which is not optimal but makes
this harder to miss.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041008/60a76077/attachment.p7s>

From bernhard at intevation.de  Fri Oct  8 16:35:58 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 8 Oct 2004 16:35:58 +0200
Subject: "Last action" fields
In-Reply-To: <200410071728.03709.dfaure@klaralvdalens-datakonsult.se>
References: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>
	<200410071508.22833.bernhard@intevation.de>
	<200410071728.03709.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410081635.58589.bernhard@intevation.de>

On Thursday 07 October 2004 17:28, David Faure wrote:
> On Thursday 07 October 2004 15:08, Bernhard Reiter wrote:
> > We do not have last-action in the specs yet,

> I'm fine with adding it and ignoring it in Kontact, but that's probably not
> what we want for full interoperability.
>
> The real question is whether we need to change korganizer's invitation
> handling or not. But I don't know enough about korganizer's invitation
> handling AND about Outlook's invitation handling to provide any useful
> input.

So we need more input from Joon here?
Actually from my occasional testing it seems that Outlook
works much better than KOrganizerin this regard.
So do you need a description of what outlook does?

> > I was immedeately thinking about doing the last action per recipient,
> > but it well might be that this modelling is enough.
>
> This is even more detailed, more than Joon requested, so I'm guessing
> Outlook (or the connector) can't do that?

Yes, but I don't know.

> > > The question is, obviously: do we need to generate such a number when
> > > the first invitation is sent from kontact?
> > > Does anyone know if (and where) this number is used in iTIP?
> >
> > No idea, maybe you can ask someone at kolab-devel and kdepim
> > if they know more?
>
> Asking a question about outlook's owner-appointment-id on kdepim?

Well there are probably more iTIP experts on there...
This is about learning what we need for groupware, so I wouldn't 
mind asking if iTIP has something like this.
 
> Doesn't look like the right place to me.

The decision is up to you of course. 
I only wanted to say the the question might go beyond this format list. ;)


> I'm not on kolab-devel at the moment; should I be? (we really have too many
> lists...)

Yes, you should.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041008/223daf20/attachment.p7s>

From bernhard at intevation.de  Fri Oct  8 17:26:43 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 8 Oct 2004 17:26:43 +0200
Subject: "Last action" fields
In-Reply-To: <200410071802.41631.reinhold@kainhofer.com>
References: <200410011740.15217.dfaure@klaralvdalens-datakonsult.se>
	<200410071728.03709.dfaure@klaralvdalens-datakonsult.se>
	<200410071802.41631.reinhold@kainhofer.com>
Message-ID: <200410081726.45986.bernhard@intevation.de>

On Thursday 07 October 2004 18:02, Reinhold Kainhofer wrote:
> On Thursday 07 October 2004 17:28, David Faure wrote:
> > On Thursday 07 October 2004 15:08, Bernhard Reiter wrote:

> > > As explained before we cannot be sure to see all revisions of
> > > an event, because other clients might work on it.
> > > So I could imagine a comparision to the change date and the
> > > last-action-date that probably is a good hint.
> >
> > Well, but we can't just make up algorithms as we want here, if this
> > is built into Outlook, can we?
>
> The icalendar spec is quite clear on this issue: The event with the higher
> revision number always wins. Changes can (shall) only be made by the
> organizer, anyway. So, basically, all icalendar-based apps will probably
> just look at the revision.

Those actions would be triggered as a diff from what has happened
last time (at least if I understand this correctly).
As with the nature of Kolab's design, as a client you cannot be sure
that you have seen or will be able to retrieve the last revision
of the event. You can only know that you have an updated one,
but you know that already without a revision field.

David is refering to how outlook operates and outlook might
keep that information in a different way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041008/6888d761/attachment.p7s>

From tarjei+a_lists.ogo at nu.no  Sun Oct 10 20:16:11 2004
From: tarjei+a_lists.ogo at nu.no (Tarjei Huse)
Date: Sun, 10 Oct 2004 20:16:11 +0200
Subject: Some input to the format documents.
Message-ID: <1097432171.5346.38.camel@linux.site>

Hi, 

I had a nice discussion with Bo on irc here the other day, and I've also
read the kolab2 format document. Based on this, I got a few suggestions
for input and discussion:

Documents as emails
I'd like to see a container for documents. I suggest that each document
is an empty email with attachments - preferably one per email and with
the name of the document as the subject. 

Reasoning: 
1) The more you can put into one repository the better. Today Kolab is
structured so that your documents will have to reside another place -
they don't have to. This will make it easier to use Kolab as _the_
document store.

2) The format must be in such a way that an simple imap-client can read
the files. I think this is more important here that wrt calendarfiles
and notes ++ because those parts it is more relevant to contain in the
users own mailhierarcy - while the documents and mails will often be
stored in shared folders. Also, there is no reason to add the complexity
of a propritary format to something that is allready defined in the
IMAP-rfcs.

Folderlinking
You should have a format for adding links between folders and other
objects. This could be used to link f.x. projects to a spesific folder.

Projects.
You should consider adding projects as a possible resourcetype that may
contain links to other kolabobjects like tasklists (one folder?), files,
members and addresses.

Addresses. 
A sad thing about moving addresses into imap is that few other clients
can read them. You should have a way to move addresses into ldap. 


Horde as the prototypeclient.
A concept that goes on top of the formats you discuss here, is the usage
of the webmailclient horde for format prototyping and development.

There are already ways to use kerberos or a Windows Domain login to
authenticate into a apache website. Using this, the user only has to be
logged into the network to access the Kolab hordesuite.

Using, this, one could see ways to produce applications first in Horde
and then other clients could implement support for the same formats
afterwords as this would take more time. Also, you could generate a
linkformat so that if the user followed a link to an object not
supported by an app (say a timesheet) the user could just follow the
link to the website and edit it there.

These are not finished thoughts, but I'd like to hear what you think
about them.

regards
Tarjei





-- 
Tarjei Huse <tarjei at nu.no>



From bo at thorsen-consulting.dk  Wed Oct 13 11:15:57 2004
From: bo at thorsen-consulting.dk (Bo Thorsen)
Date: Wed, 13 Oct 2004 11:15:57 +0200
Subject: Text Remarks
In-Reply-To: <200410071629.16078.bernhard@intevation.de>
References: <200410071629.16078.bernhard@intevation.de>
Message-ID: <200410131115.57669.bo@thorsen-consulting.dk>

On Thursday 07 October 2004 16:29, Bernhard Reiter wrote:
> later:
> ? ? This is all quite restricted, but this is the only way Outlook can
> do it... This does not seem to be a good and correct statement to make,
> because both client worlds clash here, not this is not the fault of one
> alone. Proposed fix: Remove the paragraph.

I saw David already removed this one.

I don't like removing it. There have already been several requests for 
stuff that is difficult to implement on various clients, and we want to 
state this somewhere.

Perhaps what we really need is a description of the problems faced, when 
someone wants to add new features. Somewhere in the very first pages. In 
this area we could also write down why we chose to make our own format.

Bo.



From bernhard at intevation.de  Wed Oct 13 11:19:44 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 13 Oct 2004 11:19:44 +0200
Subject: Text Remarks
In-Reply-To: <200410131115.57669.bo@thorsen-consulting.dk>
References: <200410071629.16078.bernhard@intevation.de>
	<200410131115.57669.bo@thorsen-consulting.dk>
Message-ID: <200410131119.44435.bernhard@intevation.de>

On Wednesday 13 October 2004 11:15, Bo Thorsen wrote:
> On Thursday 07 October 2004 16:29, Bernhard Reiter wrote:
> > later:
> >     This is all quite restricted, but this is the only way Outlook can
> > do it... This does not seem to be a good and correct statement to make,
> > because both client worlds clash here, not this is not the fault of one
> > alone. Proposed fix: Remove the paragraph.
>
> I saw David already removed this one.
>
> I don't like removing it.

> There have already been several requests for
> stuff that is difficult to implement on various clients, and we want to
> state this somewhere.
>
> Perhaps what we really need is a description of the problems faced, when
> someone wants to add new features. Somewhere in the very first pages. In
> this area we could also write down why we chose to make our own format.

I agree that we should add a section about explaning our reasons,
it was only important to me to not falsely blame that on Outlook,
because it really shed the wrong light on the issue.

Can you propose a paragraph?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041013/ff6c878a/attachment.p7s>

From bernhard at intevation.de  Wed Oct 13 11:32:08 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 13 Oct 2004 11:32:08 +0200
Subject: Some input to the format documents.
In-Reply-To: <1097432171.5346.38.camel@linux.site>
References: <1097432171.5346.38.camel@linux.site>
Message-ID: <200410131132.11099.bernhard@intevation.de>

Hi Tarjei,

it is great to get your thoughtful comments!
You are raising very interesting issues
and I am quite sure that we cannot solve them all
for Kolab2 as we hope to wrap that up relatively soon.
Of course there will be progress after this.

I will give my thoughts in different threats
(and probably with some delays. ;) )
Some of your questions probably are beyond the
scope of the format list and should better be discussed
on the kolab-devel list as this list should mainly
be about how to get the decided features stored
and not about what issues to be stored.

Regards,
Bernhard


On Sunday 10 October 2004 20:16, Tarjei Huse wrote:
> Documents as emails

> Folderlinking

> Projects.

> Addresses.

> Horde as the prototypeclient.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041013/1ee3fca3/attachment.p7s>

From bo at thorsen-consulting.dk  Wed Oct 13 11:49:05 2004
From: bo at thorsen-consulting.dk (Bo Thorsen)
Date: Wed, 13 Oct 2004 11:49:05 +0200
Subject: Some input to the format documents.
In-Reply-To: <200410131132.11099.bernhard@intevation.de>
References: <1097432171.5346.38.camel@linux.site>
	<200410131132.11099.bernhard@intevation.de>
Message-ID: <200410131149.05929.bo@thorsen-consulting.dk>

On Wednesday 13 October 2004 11:32, Bernhard Reiter wrote:
> Hi Tarjei,
>
> it is great to get your thoughtful comments!
> You are raising very interesting issues
> and I am quite sure that we cannot solve them all
> for Kolab2 as we hope to wrap that up relatively soon.
> Of course there will be progress after this.
>
> I will give my thoughts in different threats

I have a feeling you meant "threads" ^ :-)

Bo.

> (and probably with some delays. ;) )
> Some of your questions probably are beyond the
> scope of the format list and should better be discussed
> on the kolab-devel list as this list should mainly
> be about how to get the decided features stored
> and not about what issues to be stored.



From bernhard at intevation.de  Wed Oct 13 12:09:42 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 13 Oct 2004 12:09:42 +0200
Subject: Some input to the format documents.
In-Reply-To: <200410131149.05929.bo@thorsen-consulting.dk>
References: <1097432171.5346.38.camel@linux.site>
	<200410131132.11099.bernhard@intevation.de>
	<200410131149.05929.bo@thorsen-consulting.dk>
Message-ID: <200410131209.42553.bernhard@intevation.de>

On Wednesday 13 October 2004 11:49, Bo Thorsen wrote:
> On Wednesday 13 October 2004 11:32, Bernhard Reiter wrote:
> > Hi Tarjei,
> >
> > it is great to get your thoughtful comments!
> > You are raising very interesting issues
> > and I am quite sure that we cannot solve them all
> > for Kolab2 as we hope to wrap that up relatively soon.
> > Of course there will be progress after this.
> >
> > I will give my thoughts in different threats
>
> I have a feeling you meant "threads" ^ :-)

Arrrg, yes "threads" as in email discussions!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041013/0a2c6355/attachment.p7s>

From tarjei+a_lists.phpgw at nu.no  Wed Oct 13 12:32:29 2004
From: tarjei+a_lists.phpgw at nu.no (Tarjei Huse)
Date: Wed, 13 Oct 2004 12:32:29 +0200
Subject: Some input to the format documents.
In-Reply-To: <200410131209.42553.bernhard@intevation.de>
References: <1097432171.5346.38.camel@linux.site>
	<200410131132.11099.bernhard@intevation.de>
	<200410131149.05929.bo@thorsen-consulting.dk>
	<200410131209.42553.bernhard@intevation.de>
Message-ID: <1097663549.416d043d226a2@mail.nu.no>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> On Wednesday 13 October 2004 11:49, Bo Thorsen wrote:
> > On Wednesday 13 October 2004 11:32, Bernhard Reiter wrote:
> > > Hi Tarjei,
> > >
> > > it is great to get your thoughtful comments!
> > > You are raising very interesting issues
> > > and I am quite sure that we cannot solve them all
> > > for Kolab2 as we hope to wrap that up relatively soon.
> > > Of course there will be progress after this.
> > >
> > > I will give my thoughts in different threats
> >
> > I have a feeling you meant "threads" ^ :-)
> 
> Arrrg, yes "threads" as in email discussions!
Hey you're not the only one making spellingmisstakes :-)

Tarjei
> 





From dfaure at klaralvdalens-datakonsult.se  Fri Oct 15 23:33:27 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Fri, 15 Oct 2004 23:33:27 +0200
Subject: Distribution lists
In-Reply-To: <200409221610.24589.bernhard@intevation.de>
References: <20040922120122.7B7AF1674F@ctb-mesg6.saix.net>
	<200409221601.38546.reinhold@kainhofer.com>
	<200409221610.24589.bernhard@intevation.de>
Message-ID: <200410152333.31504.dfaure@klaralvdalens-datakonsult.se>

Replying to an old mail, since the discussion wasn't finished, and I'm working on
personal distribution lists now.

On Wednesday 22 September 2004 16:10, Bernhard Reiter wrote:
> On Wednesday 22 September 2004 16:01, Reinhold Kainhofer wrote:
> > On Wednesday,  22. September 2004 15:41, Bernhard Reiter wrote:
> > > It depends on what we want those distributions lists for.
> > > A distribution list based on email addresses is simpler to handle,
> > > but one which is tired to a contact also has advantages.
> >
> > I don't think that lists based on email addresses are simpler to handle. In
> > particular, if you change the  email address of a contact, you'll have to
> > check all distributions lists if they contained the old email address, and
> > in that case update them to the new email address. With uid-based lists,
> > you get that automatically.
> 
> Well if you have ten different contact folders, how do we ensure that the uids
> are unique? 

There was a discussion on kdepim about unicity of uids, and it was determined that
the likelyhood of generating the same uid for two completely different contacts
is VERY VERY small. If it ever happens, the user will get a conflict dialog even
before anything bad can happen with distribution lists, anyway. I don't think
we have to care for the 0.000001% likelihood, which would create other problems anyway.

> If as another person you can only read five out of those contact 
> folders, what do you make out of the other uids that you cannot resolve?

Well, then you can't use them. Same thing when deleting a contact.
And as long as you don't edit the distr list, those uids are not lost from it.

It seems to me that both Outlook and Kontact use a list of { UID + optionnal email },
(where the optional email is used to choose the right email in the given contact,
which is useful when it has more than one),
so how about we standardize on that in the XML format?

<distribution-list>
[...]
<!-- Distribution List specific attributes -->
<display-name>(string)</display-name>
{
  <member>
    <uid>(string)</uid>
    [<smtp-address>(string)</smtp-address>]
  </member>
}
</distribution-list>

In Kontact's case it would be even simpler to keep the same mimetype (contact),
since currently each folder contains things of only one mimetype - but I can also do 
with a separate mimetype if that's simpler for you.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From joon at radleys.co.za  Sat Oct 16 07:01:20 2004
From: joon at radleys.co.za (Joon Radley)
Date: Sat, 16 Oct 2004 07:01:20 +0200
Subject: Distribution lists
In-Reply-To: <200410152333.31504.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>

Hi David,

> -----Original Message-----
> From: kolab-format-bounces at kolab.org 
> [mailto:kolab-format-bounces at kolab.org] On Behalf Of David Faure
> Sent: Friday, October 15, 2004 11:33 PM
> To: kolab-format at kolab.org
> Subject: Re: Distribution lists

 
> It seems to me that both Outlook and Kontact use a list of { 
> UID + optionnal email }, (where the optional email is used to 
> choose the right email in the given contact, which is useful 
> when it has more than one), so how about we standardize on 
> that in the XML format?
> 
> <distribution-list>
> [...]
> <!-- Distribution List specific attributes --> 
> <display-name>(string)</display-name>
> {
>   <member>
>     <uid>(string)</uid>
>     [<smtp-address>(string)</smtp-address>]
>   </member>
> }
> </distribution-list>
> 
> In Kontact's case it would be even simpler to keep the same 
> mimetype (contact), since currently each folder contains 
> things of only one mimetype - but I can also do with a 
> separate mimetype if that's simpler for you.

The UID's in Outlook is a relative UID to a message store. It is not unique
across multiple message stores. Therefore it cannot be used as UID for this
object.

The whole resolution in Outlook is based on the fact that an email address
and display name is the UID for the contact. To support some arbitrary UID
will be an absolute nightmare for me.

Could we please just focus on why a display name and email address cannot be
used as the UID before we consider a generated UID.

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



From dfaure at klaralvdalens-datakonsult.se  Mon Oct 18 19:44:10 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Mon, 18 Oct 2004 19:44:10 +0200
Subject: Distribution lists
In-Reply-To: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>
References: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>
Message-ID: <200410181944.15157.dfaure@klaralvdalens-datakonsult.se>

On Saturday 16 October 2004 07:01, Joon Radley wrote:
> The UID's in Outlook is a relative UID to a message store. It is not unique
> across multiple message stores. Therefore it cannot be used as UID for this
> object.

You are saying that the UID used in <event><uid>...</uid> could be the same
in different folders? This is going to create trouble in kontact if it ever happens.
Well, only one will appear. In a discussion on the same issue on another list,
we came to the conclusion that this is a very very rare possibility and it isn't
really a problem to do it that way. But OK.

> The whole resolution in Outlook is based on the fact that an email address
> and display name is the UID for the contact. To support some arbitrary UID
> will be an absolute nightmare for me.

OK, then it looks like it has to be email+display name :(

> Could we please just focus on why a display name and email address cannot be
> used as the UID before we consider a generated UID.
Well, it's generated but it's also what we have in the <contact> XML already....

If we use email address + display name... what happens when someone
makes a change to a display name? E.g. to add "Dr." or change the name
after being married, etc.? I guess the link to the distr. list would then be lost.
But ok that's probably relatively rare too....

I'm OK with display_name+email then, it certainly makes sense in the XML even if
in kontact we convert that to and from uid+optional_email.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Mon Oct 18 19:50:11 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Mon, 18 Oct 2004 19:50:11 +0200
Subject: Distribution lists
In-Reply-To: <200410181944.15157.dfaure@klaralvdalens-datakonsult.se>
References: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>
	<200410181944.15157.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410181950.12180.martin.konold@erfrakon.de>

Am Montag, 18. Oktober 2004 19:44 schrieb David Faure:

Hi,

> after being married, etc.? I guess the link to the distr. list would then
> be lost. But ok that's probably relatively rare too....

I think this is acceptable as Kolab never is about relational coherency.

We have many more places which can fall apart.

BTW: Why do we need email address + Display name? The primary email address 
should already be unique.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Wed Oct 20 15:01:03 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 20 Oct 2004 15:01:03 +0200
Subject: Distribution lists
In-Reply-To: <200410181950.12180.martin.konold@erfrakon.de>
References: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>
	<200410181944.15157.dfaure@klaralvdalens-datakonsult.se>
	<200410181950.12180.martin.konold@erfrakon.de>
Message-ID: <200410201501.03930.dfaure@klaralvdalens-datakonsult.se>

OK I added <distribution-list> as specified by Joon to the format spec
and implemented it in kontact now.

On Monday 18 October 2004 19:50, Martin Konold wrote:
> BTW: Why do we need email address + Display name? The primary email address 
> should already be unique.
It's not - see Bo's mails about members of his family sharing the same email address.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar?lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Thu Oct 21 07:13:28 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Thu, 21 Oct 2004 07:13:28 +0200
Subject: Distribution lists
In-Reply-To: <200410201501.03930.dfaure@klaralvdalens-datakonsult.se>
References: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>
	<200410181950.12180.martin.konold@erfrakon.de>
	<200410201501.03930.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410210713.29326.martin.konold@erfrakon.de>

Am Mittwoch, 20. Oktober 2004 15:01 schrieb David Faure:

Hi,

> It's not - see Bo's mails about members of his family sharing the same
> email address.

From the point of view of Kolab this makes imho not much sense. With Kolab 
every person/account has a unique email address. 

If like in the case of Bo's family some people are sharing a single email 
address (imho not really required with modern technology as email addresses 
are really cheap) they have in the Kolab modelling concept to be treated like 
a single entity.

On the other hand the usage of the additional proprty display name does _hurt_ 
for the simple reason that we _intentionally_ allow the changing of the users 
name while we dissallow the changing of the primary email address.

We require this in the case a marriage etc. In such a case we allow to change 
the display name (e.g. firstname and newlastname) or new titles like Dr.. 
While the primary email address remains  we add a new alias which reflect the 
new names (e.g. firstname.newlastname at kolab.tld)

Yours,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Thu Oct 21 16:54:41 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Thu, 21 Oct 2004 16:54:41 +0200
Subject: Distribution lists
In-Reply-To: <200410210713.29326.martin.konold@erfrakon.de>
References: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>
	<200410201501.03930.dfaure@klaralvdalens-datakonsult.se>
	<200410210713.29326.martin.konold@erfrakon.de>
Message-ID: <200410211654.44755.dfaure@klaralvdalens-datakonsult.se>

On Thursday 21 October 2004 07:13, Martin Konold wrote:
> Am Mittwoch, 20. Oktober 2004 15:01 schrieb David Faure:
> 
> Hi,
> 
> > It's not - see Bo's mails about members of his family sharing the same
> > email address.
> 
> From the point of view of Kolab this makes imho not much sense. With Kolab 
> every person/account has a unique email address. 

That is true, but someone's contacts are not all on the kolab server.
So those contacts don't follow the "email is unique" rule.

> If like in the case of Bo's family some people are sharing a single email 
> address (imho not really required with modern technology as email addresses 
> are really cheap) they have in the Kolab modelling concept to be treated like 
> a single entity.

*If* they were kolab users. But they're not. I can be a kolab user, and send mail
to my parents, which are not. And my parents share the same email address.

> On the other hand the usage of the additional proprty display name does _hurt_ 
> for the simple reason that we _intentionally_ allow the changing of the users 
> name while we dissallow the changing of the primary email address.

Yes, so this simply means the display-name should be used to disambiguate
if multiple matches are found for a given email, but if no contact has that
display-name, we still pick the (first) one with that email.
So the display-name is just a hint.
I'll fix my code accordingly now :)

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Fri Oct 22 06:52:25 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Fri, 22 Oct 2004 06:52:25 +0200
Subject: Distribution lists
In-Reply-To: <200410211654.44755.dfaure@klaralvdalens-datakonsult.se>
References: <20041016050117.8A92EC1F8@ctb-mesg6.saix.net>
	<200410210713.29326.martin.konold@erfrakon.de>
	<200410211654.44755.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410220652.26607.martin.konold@erfrakon.de>

Am Donnerstag, 21. Oktober 2004 16:54 schrieb David Faure:

Hi David,

> Yes, so this simply means the display-name should be used to disambiguate
> if multiple matches are found for a given email, but if no contact has that
> display-name, we still pick the (first) one with that email.
> So the display-name is just a hint.
> I'll fix my code accordingly now :)

I am very happy about this solution.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Mon Oct 25 13:36:12 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Mon, 25 Oct 2004 13:36:12 +0200
Subject: freebusy annotations
In-Reply-To: <200409290119.48623.martin.konold@erfrakon.de>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200409290025.22214.dfaure@klaralvdalens-datakonsult.se>
	<200409290119.48623.martin.konold@erfrakon.de>
Message-ID: <200410251336.15786.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 29 September 2004 01:19, Martin Konold wrote:
> Am Mittwoch, 29. September 2004 00:25 schrieb David Faure:
> > Then it could be
> > annotation: /vendor/kolab/generate-freebusy    (or something like that)
> > attribute: value.shared
> > value: true or false

After more discussion we came up with the following idea instead:

A calendar folder is either 
* not relevant for freebusy for anyone,
* relevant for the owner of the folder only
or
* relevant for anyone who can read the folder

This would be modelled with an annotation /vendor/kolab/freebusy-relevant,
where the attribute value.shared could have the values "none", "owner", "readers".
By default, if the attribute isn't set, "owner" would be assumed.

The question remains whether this is tied to alarms or not.
In my opinion if a folder is freebusy-relevant for someone, then alarms must
go off for that person, it's indeed the same setting. Either you're going to
the meeting (then it's both fb-relevant and alarm-relevant) or you're just
watching someone else's calendar (and then it's not fb-relevant for you
neither alarm-relevant). The other person is going to the meeting, not you.

OK with everyone?

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From dfaure at klaralvdalens-datakonsult.se  Mon Oct 25 14:39:14 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Mon, 25 Oct 2004 14:39:14 +0200
Subject: freebusy annotations
In-Reply-To: <200410251336.15786.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200409290119.48623.martin.konold@erfrakon.de>
	<200410251336.15786.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410251439.20347.dfaure@klaralvdalens-datakonsult.se>

On Monday 25 October 2004 13:36, David Faure wrote:
> On Wednesday 29 September 2004 01:19, Martin Konold wrote:
> > Am Mittwoch, 29. September 2004 00:25 schrieb David Faure:
> > > Then it could be
> > > annotation: /vendor/kolab/generate-freebusy    (or something like that)
> > > attribute: value.shared
> > > value: true or false
> 
> After more discussion we came up with the following idea instead:
> 
> A calendar folder is either 
> * not relevant for freebusy for anyone,
> * relevant for the owner of the folder only
> or
> * relevant for anyone who can read the folder
> 
> This would be modelled with an annotation /vendor/kolab/freebusy-relevant,

Let me rephrase that to /vendor/kolab/freebusy-relevance
It looks less like a boolean that way :)

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From bernhard at intevation.de  Mon Oct 25 16:25:12 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 25 Oct 2004 16:25:12 +0200
Subject: freebusy annotations
In-Reply-To: <200410251336.15786.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200409290119.48623.martin.konold@erfrakon.de>
	<200410251336.15786.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410251625.18067.bernhard@intevation.de>

On Monday 25 October 2004 13:36, David Faure wrote:
> On Wednesday 29 September 2004 01:19, Martin Konold wrote:
> > Am Mittwoch, 29. September 2004 00:25 schrieb David Faure:
> > > Then it could be
> > > annotation: /vendor/kolab/generate-freebusy    (or something like that)
> > > attribute: value.shared
> > > value: true or false
>
> After more discussion we came up with the following idea instead:
>
> A calendar folder is either
> * not relevant for freebusy for anyone,
> * relevant for the owner of the folder only
> or
> * relevant for anyone who can read the folder
>
> This would be modelled with an annotation /vendor/kolab/freebusy-relevant,
> where the attribute value.shared could have the values "none", "owner",
> "readers". By default, if the attribute isn't set, "owner" would be
> assumed.
>
> The question remains whether this is tied to alarms or not.
> In my opinion if a folder is freebusy-relevant for someone, then alarms
> must go off for that person, it's indeed the same setting. Either you're
> going to the meeting (then it's both fb-relevant and alarm-relevant) or
> you're just watching someone else's calendar (and then it's not fb-relevant
> for you neither alarm-relevant). The other person is going to the meeting,
> not you.
>
> OK with everyone?

Yes  (also with your followup on the name of the annotation).
There is one question: 
What about notes and tasks folders for which we would require a
similiar annotation, but only for reminders (aka alarms).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041025/1b7cd56f/attachment.p7s>

From dfaure at klaralvdalens-datakonsult.se  Mon Oct 25 16:43:04 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Mon, 25 Oct 2004 16:43:04 +0200
Subject: freebusy annotations
In-Reply-To: <200410251625.18067.bernhard@intevation.de>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410251336.15786.dfaure@klaralvdalens-datakonsult.se>
	<200410251625.18067.bernhard@intevation.de>
Message-ID: <200410251643.09111.dfaure@klaralvdalens-datakonsult.se>

On Monday 25 October 2004 16:25, Bernhard Reiter wrote:
> There is one question: 
> What about notes and tasks folders for which we would require a
> similiar annotation, but only for reminders (aka alarms).

Oh. Then maybe we should rename the annotation to, hmmm....
/vendor/kolab/incidences-for ?
/vendor/kolab/relevant-for ?
/vendor/kolab/incidences-relevance ?

(still with none, owner, readers as values. Hmm, maybe none should be nobody?)

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From dfaure at klaralvdalens-datakonsult.se  Mon Oct 25 20:22:52 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Mon, 25 Oct 2004 20:22:52 +0200
Subject: freebusy annotations
In-Reply-To: <200410251643.09111.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410251625.18067.bernhard@intevation.de>
	<200410251643.09111.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410252022.53483.dfaure@klaralvdalens-datakonsult.se>

On Monday 25 October 2004 16:43, David Faure wrote:
> On Monday 25 October 2004 16:25, Bernhard Reiter wrote:
> > There is one question: 
> > What about notes and tasks folders for which we would require a
> > similiar annotation, but only for reminders (aka alarms).
> 
> Oh. Then maybe we should rename the annotation to, hmmm....
> /vendor/kolab/incidences-for ?
> /vendor/kolab/relevant-for ?
> /vendor/kolab/incidences-relevance ?

Still thinking about naming, and semantics...

In fact this is quite related to the "attendees" of the incidence, isn't it?

Except that I could create an event where Till is an attendee, and keep it in 
my calendar, and this shouldn't generate freebusy and alarms for Till, since
he would have no way to fix that. That's the problem of correctness of the
information, but in a perfect world an incidence would simply relevant to 
whoever attends it. So while we don't want to actually parse incidences and
read the attendees from it, the semantic is still something like that.
So, unless this is too confusing, the freebusy-and-alarm-relevance annotation
could be named /vendor/kolab/attendees : "nobody", "owner", "readers"  (*)


(*) I just thought that "writers" could be useful too. If a calendar folder 
is shared by N people that are part of a working group (and have write
access to that calendar), and a few other people can read this calendar
for their information (secretary, higher-level boss, etc.), then the "attendees"
are the members of the group, but not the mere lurkers. Just a thought;
can always be implemented later.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From bernhard at intevation.de  Mon Oct 25 21:30:08 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 25 Oct 2004 21:30:08 +0200
Subject: freebusy annotations
In-Reply-To: <200410252022.53483.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410251643.09111.dfaure@klaralvdalens-datakonsult.se>
	<200410252022.53483.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410252130.13577.bernhard@intevation.de>

On Monday 25 October 2004 20:22, David Faure wrote:
> On Monday 25 October 2004 16:43, David Faure wrote:
> > On Monday 25 October 2004 16:25, Bernhard Reiter wrote:
> > > There is one question:
> > > What about notes and tasks folders for which we would require a
> > > similiar annotation, but only for reminders (aka alarms).
> >
> > Oh. Then maybe we should rename the annotation to, hmmm....
> > /vendor/kolab/incidences-for ?
> > /vendor/kolab/relevant-for ?
> > /vendor/kolab/incidences-relevance ?
>
> Still thinking about naming, and semantics...
>
> In fact this is quite related to the "attendees" of the incidence, isn't
> it?

IMO we do not want this to act differently on who is attending,
this introduces a new class of complexity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041025/d1cb4623/attachment.p7s>

From dfaure at klaralvdalens-datakonsult.se  Mon Oct 25 21:34:07 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Mon, 25 Oct 2004 21:34:07 +0200
Subject: freebusy annotations
In-Reply-To: <200410252130.13577.bernhard@intevation.de>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410252022.53483.dfaure@klaralvdalens-datakonsult.se>
	<200410252130.13577.bernhard@intevation.de>
Message-ID: <200410252134.08506.dfaure@klaralvdalens-datakonsult.se>

On Monday 25 October 2004 21:30, Bernhard Reiter wrote:
> On Monday 25 October 2004 20:22, David Faure wrote:
> > On Monday 25 October 2004 16:43, David Faure wrote:
> > > On Monday 25 October 2004 16:25, Bernhard Reiter wrote:
> > > > There is one question:
> > > > What about notes and tasks folders for which we would require a
> > > > similiar annotation, but only for reminders (aka alarms).
> > >
> > > Oh. Then maybe we should rename the annotation to, hmmm....
> > > /vendor/kolab/incidences-for ?
> > > /vendor/kolab/relevant-for ?
> > > /vendor/kolab/incidences-relevance ?
> >
> > Still thinking about naming, and semantics...
> >
> > In fact this is quite related to the "attendees" of the incidence, isn't
> > it?
> 
> IMO we do not want this to act differently on who is attending,
> this introduces a new class of complexity.

Yes, I agree... This is exactly what I was saying in the rest of the mail....

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From dfaure at klaralvdalens-datakonsult.se  Wed Oct 27 13:08:51 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 27 Oct 2004 13:08:51 +0200
Subject: OL recurrence question
Message-ID: <200410271308.52090.dfaure@klaralvdalens-datakonsult.se>

Hi Joon,

Can Outlook handle recurrences like 
"every last thursday of the month" ?

In ical this is RRULE:FREQ=MONTHLY;BYDAY=TH;BYSETPOS=-1

The XML for it could be like
  <daynumber>-1</daynumber>
  <day>thursday</day>

but does outlook support this notion?

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From reinhold at kainhofer.com  Wed Oct 27 13:22:28 2004
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed, 27 Oct 2004 13:22:28 +0200
Subject: OL recurrence question
In-Reply-To: <200410271308.52090.dfaure@klaralvdalens-datakonsult.se>
References: <200410271308.52090.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410271322.30969.reinhold@kainhofer.com>

On Wednesday 27 October 2004 13:08, David Faure wrote:
> Hi Joon,
>
> Can Outlook handle recurrences like
> "every last thursday of the month" ?
>
> In ical this is RRULE:FREQ=MONTHLY;BYDAY=TH;BYSETPOS=-1

Last thursday of the month would be (no bysetpos needed):
RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=-1TH
Yours is not wrong, but too complicated.

However, last weekday of the month needs to be written as 
RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
or the first weekday:
RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1

Or the first month-start of each year that falls on a monday:
RRULE:FREQ=YEARLY;BYDAY=MO;BYMONTHDAY=1;BYSETPOS=1

libkcal can't hande bysetpos currently at all.

> The XML for it could be like
>   <daynumber>-1</daynumber>

Wouldn't that indicate the date (e.g. the 27th), instead of the index in the 
set of dates generated by the RRULE?

>   <day>thursday</day>
>
> but does outlook support this notion?

Evolution certainly does, but that's off-topic for kolab...

Reinhold
-- 
------------------------------------------------------------------
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/20041027/1459c521/attachment.sig>

From joon at radleys.co.za  Wed Oct 27 13:40:08 2004
From: joon at radleys.co.za (Joon Radley)
Date: Wed, 27 Oct 2004 13:40:08 +0200
Subject: OL recurrence question
In-Reply-To: <200410271308.52090.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <20041027114007.5CAB81A89EC@ctb-mesg5.saix.net>

Hi David,

No it does not support this option. The best you can do is "every 4th
Thursday of the month"

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


> -----Original Message-----
> From: kolab-format-bounces at kolab.org 
> [mailto:kolab-format-bounces at kolab.org] On Behalf Of David Faure
> Sent: Wednesday, October 27, 2004 1:09 PM
> To: kolab-format at kolab.org
> Subject: OL recurrence question
> 
> Hi Joon,
> 
> Can Outlook handle recurrences like
> "every last thursday of the month" ?
> 
> In ical this is RRULE:FREQ=MONTHLY;BYDAY=TH;BYSETPOS=-1
> 
> The XML for it could be like
>   <daynumber>-1</daynumber>
>   <day>thursday</day>
> 
> but does outlook support this notion?
> 
> --
> David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
> Qt/KDE/KOffice developer
> Klar??lvdalens Datakonsult AB, Platform-independent software solutions
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format



From dfaure at klaralvdalens-datakonsult.se  Wed Oct 27 14:08:43 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 27 Oct 2004 14:08:43 +0200
Subject: freebusy annotations
In-Reply-To: <200410252134.08506.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410252130.13577.bernhard@intevation.de>
	<200410252134.08506.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410271408.44311.dfaure@klaralvdalens-datakonsult.se>

OK after a discussion with Martin on IRC we decided on
/vendor/kolab/incidences-for
with value.shared set to "nobody", "owner" or "readers".
If the annotation isn't there, "owner" should be assumed.

Martin updated the concept paper accordingly (we agreed that this isn't
something for the kolab XML specification).

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From dfaure at klaralvdalens-datakonsult.se  Wed Oct 27 14:19:49 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 27 Oct 2004 14:19:49 +0200
Subject: freebusy annotations
In-Reply-To: <200410251625.18067.bernhard@intevation.de>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410251336.15786.dfaure@klaralvdalens-datakonsult.se>
	<200410251625.18067.bernhard@intevation.de>
Message-ID: <200410271419.50600.dfaure@klaralvdalens-datakonsult.se>

On Monday 25 October 2004 16:25, Bernhard Reiter wrote:
> What about notes and tasks folders for which we would require a
> similiar annotation, but only for reminders (aka alarms).

Notes don't have alarms, do they? They are not incidences.
Journals are incidences, but well, alarms don't make much sense for them.
So I think this only applies to calendar and task folders.
Bernhard: do you agree? 
If yes, Martin: please update the concept paper accordingly, IIRC you mentionned
notes there too.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From dfaure at klaralvdalens-datakonsult.se  Wed Oct 27 19:57:51 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 27 Oct 2004 19:57:51 +0200
Subject: freebusy annotations
In-Reply-To: <200410271408.44311.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410252134.08506.dfaure@klaralvdalens-datakonsult.se>
	<200410271408.44311.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410271958.01249.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 27 October 2004 14:08, David Faure wrote:
> OK after a discussion with Martin on IRC we decided on
> /vendor/kolab/incidences-for
> with value.shared set to "nobody", "owner" or "readers".

Little problem here: it's easy for the server ('s freebusy script)
to know who's the owner of a folder.
But it's not easy for the client to find that out - not with cyrus-specific 
heuristics, which we might as well avoid if possible.

=> Would it be OK to remove "owner" and add "admins" instead?
"admins" would mean: anyone with ACL Admin rights on the folder.
This is easier to check, and very consistent with "readers".

In the boss/secretary scenario, would it be correct to say that the secretary
won't have Admin permissions on the boss' folders? I don't think he/she
needs it, only Write permissions.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
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: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20041027/c080d039/attachment.sig>

From martin.konold at erfrakon.de  Wed Oct 27 22:13:14 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 27 Oct 2004 22:13:14 +0200
Subject: freebusy annotations
In-Reply-To: <200410271958.01249.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410271408.44311.dfaure@klaralvdalens-datakonsult.se>
	<200410271958.01249.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410272213.15018.martin.konold@erfrakon.de>

Am Mittwoch, 27. Oktober 2004 19:57 schrieb David Faure:

Hi David,

> But it's not easy for the client to find that out - not with cyrus-specific
> heuristics, which we might as well avoid if possible.

Well, you can simply look at the path of the folder and then you will see that 
it is a subfolder of the inbox which tells you that it is an account and not 
an anoymous shared folder.

> => Would it be OK to remove "owner" and add "admins" instead?
> "admins" would mean: anyone with ACL Admin rights on the folder.
> This is easier to check, and very consistent with "readers".

I think this is a real option but of course it means granting admin permission 
has then unexpected side effects.

What do other think? What about the usability of such a semantic?

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Wed Oct 27 22:19:45 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 27 Oct 2004 22:19:45 +0200
Subject: freebusy annotations
In-Reply-To: <200410272213.15018.martin.konold@erfrakon.de>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410271958.01249.dfaure@klaralvdalens-datakonsult.se>
	<200410272213.15018.martin.konold@erfrakon.de>
Message-ID: <200410272219.46211.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 27 October 2004 22:13, Martin Konold wrote:
> Am Mittwoch, 27. Oktober 2004 19:57 schrieb David Faure:
> 
> Hi David,
> 
> > But it's not easy for the client to find that out - not with cyrus-specific
> > heuristics, which we might as well avoid if possible.
> 
> Well, you can simply look at the path of the folder and then you will see that 
> it is a subfolder of the inbox which tells you that it is an account and not 
> an anoymous shared folder.

As I said, that's cyrus-specific. With other IMAP servers your folders are not under your INBOX.

> > => Would it be OK to remove "owner" and add "admins" instead?
> > "admins" would mean: anyone with ACL Admin rights on the folder.
> > This is easier to check, and very consistent with "readers".
> 
> I think this is a real option but of course it means granting admin permission 
> has then unexpected side effects.

Yes. A documented one, but indeed "admins" would be the default, so....
well it's true sharing: events apply to both persons, both are admins, etc.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From martin.konold at erfrakon.de  Wed Oct 27 22:28:36 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 27 Oct 2004 22:28:36 +0200
Subject: freebusy annotations
In-Reply-To: <200410272219.46211.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410272213.15018.martin.konold@erfrakon.de>
	<200410272219.46211.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410272228.36596.martin.konold@erfrakon.de>

Am Mittwoch, 27. Oktober 2004 22:19 schrieb David Faure:

Hi David,

> As I said, that's cyrus-specific. With other IMAP servers your folders are
> not under your INBOX.

Well, the Kolab server developed in the meantime many dependencies on cyrus 
and other (modified) components.

> > I think this is a real option but of course it means granting admin
> > permission has then unexpected side effects.
>
> Yes. A documented one, but indeed "admins" would be the default, so....
> well it's true sharing: events apply to both persons, both are admins, etc.

If noone objects I will follow your proposal.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From dfaure at klaralvdalens-datakonsult.se  Wed Oct 27 22:31:55 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Wed, 27 Oct 2004 22:31:55 +0200
Subject: freebusy annotations
In-Reply-To: <200410272228.36596.martin.konold@erfrakon.de>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410272219.46211.dfaure@klaralvdalens-datakonsult.se>
	<200410272228.36596.martin.konold@erfrakon.de>
Message-ID: <200410272231.56199.dfaure@klaralvdalens-datakonsult.se>

On Wednesday 27 October 2004 22:28, Martin Konold wrote:
> Am Mittwoch, 27. Oktober 2004 22:19 schrieb David Faure:
> 
> Hi David,
> 
> > As I said, that's cyrus-specific. With other IMAP servers your folders are
> > not under your INBOX.
> 
> Well, the Kolab server developed in the meantime many dependencies on cyrus 
> and other (modified) components.

The server, yes.
But I'm talking about KMail here. If we use this annotation for alarms, then KMail
has to be able to implement the various values for this annotation, and "owner" is a problem.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From bo at thorsen-consulting.dk  Thu Oct 28 12:34:24 2004
From: bo at thorsen-consulting.dk (Bo Thorsen)
Date: Thu, 28 Oct 2004 12:34:24 +0200
Subject: RFC: Splitting the UID concept of tasks and events
Message-ID: <200410281234.29457.bo@thorsen-consulting.dk>

Hi all,

I just checked a patch into the KDE client that changes the UID concept a 
bit for tasks and events (aka incidences).

The problem is, that many iCal based clients use the UID as a persistent 
handle to other incidences. This works fine until you have access to 
other peoples folders that can have an event with the same UID.

The UID can be identical between two events only when you receive an 
invitation from someone. The event or task saved from that has the same 
UID as the invitation mail. This means, that if you have access to some 
persons calendar and both of you accept an invitation, you will both have 
an event with identical UIDs.

The reason you keep the invitation UID is to match incoming changes to the 
incidence with your local stored copy. So when you get an update mail, 
the old version is updated with the new information - or at least 
replaced with the new version of it.

This is a fundamental flaw in iCalendar, and there is not much to do other 
than to try and work around it.

The fix I came up with is fairly simple: Introduce a scheduling ID. This 
SID is always identical to the UID, unless the event comes from accepting 
an incidence. If this is the case, the SID is the same as the UID of the 
invitation, and UID gets a new unique value.

I have something like this:

Incidence {
  ID getSchedulingID():
    if( hasSID )
      return sid
    return uid
}

This means that for all scheduling, you just use the SID in the future, 
and for all else, keep continuing to use the UID.

Actually there was only four places (I think) in the iCal library of 
kdepim where I needed to change from using the UID to SID, so it's most 
likely not a huge task.

For storing the incidence in iCal, I save the SID in the iCal UID field, 
since the SID is *always exactly* identical to what the UID used to be. 
If UID is not the same as SID (or hasID in the code up there is true), I 
also save a field X-KDE-LIBKCAL-ID that holds the UID. The reason it's 
done like this is that all other iCal applications won't know something 
happened.

I could do the same for the Kolab resource implementation also, but I 
would much prefer to introduce a <scheduling-id> tag instead, that would 
only be present if it is not the same as <uid>. So this change will only 
do something for the incidences you have that comes from accepting an 
invitation.

We currently have four clients.

- The KDE client is quickly done, since I already coded this and have been 
testing it thoroughly over the last couple of weeks.

- AFAIR, Joon once told me that Outlook doesn't use the UID for 
uniqueness, so this part is not a problem. Loading would then mean only 
the SID has a meaning. Saving would mean finding out that this comes from 
an invitation, picking out the UID from the invitation, and saving that 
in SID. And of course come up with some UID.

- Horde would most likely need more or less the same changes as the KDE 
client. I can mail the patch, so you can see exactly what changes was 
done.

- The automatic scheduling code in the server needs to have the same 
changes - save SID on accepting invitations and searching for SID on 
updates.

I don't know how much code is shared between the webclient and the auto 
scheduling stuff, so I can't say if you can share some of the load of 
this.

Implementing the patch took me only some hours. Testing it to be sure it 
worked took a long time. But it's not a big implementation issue.

What do you think about this?

Bo.

(Note: Please keep Till in the CC:)
-------------- 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/20041028/8f8b5025/attachment.sig>

From martin.konold at erfrakon.de  Thu Oct 28 20:43:17 2004
From: martin.konold at erfrakon.de (Martin Konold)
Date: Thu, 28 Oct 2004 20:43:17 +0200
Subject: RFC: Splitting the UID concept of tasks and events
In-Reply-To: <200410281234.29457.bo@thorsen-consulting.dk>
References: <200410281234.29457.bo@thorsen-consulting.dk>
Message-ID: <200410282043.18167.martin.konold@erfrakon.de>

Am Donnerstag, 28. Oktober 2004 12:34 schrieb Bo Thorsen:

Hi Bo,

> Implementing the patch took me only some hours. Testing it to be sure it
> worked took a long time. But it's not a big implementation issue.
>
> What do you think about this?

I think this is a very interesting concept and cannot find a problem with it 
right away. I therefore propose to seriously consider it!

> (Note: Please keep Till in the CC:)

Till: Please also subscribe to this high S/N list.

Regards,
-- martin

"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From steffen at klaralvdalens-datakonsult.se  Fri Oct 29 02:38:14 2004
From: steffen at klaralvdalens-datakonsult.se (Steffen Hansen)
Date: Fri, 29 Oct 2004 02:38:14 +0200
Subject: RFC: Splitting the UID concept of tasks and events
In-Reply-To: <200410281234.29457.bo@thorsen-consulting.dk>
References: <200410281234.29457.bo@thorsen-consulting.dk>
Message-ID: <200410290238.14304.steffen@klaralvdalens-datakonsult.se>

On Thursday 28 October 2004 12:34, Bo Thorsen wrote:
> Hi all,
>
> I just checked a patch into the KDE client that changes the UID
> concept a bit for tasks and events (aka incidences).
[...]
> - The automatic scheduling code in the server needs to have the same
> changes - save SID on accepting invitations and searching for SID on
> updates.

What does this do to the kolab xml format? Right now we have the UID in 
the Subject: of the mail used for storage -- that makes it much faster 
for me to search for a particular event. Can we agree on a header or 
something for the SID? Like

X-Kolab-SID:  foobar-4711

regards
-- 
Steffen Hansen          |       Klar?lvdalens Datakonsult AB
Senior Software Engineer|       http://www.klaralvdalens-datakonsult.se
                        |
                        |       Platform-independent
                        |       software solutions



From bernhard at intevation.de  Fri Oct 29 12:47:27 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 29 Oct 2004 12:47:27 +0200
Subject: Mangle the format?
Message-ID: <200410291247.33440.bernhard@intevation.de>

The recent HTML mangeling tests
that turned up bugs in basically all webbrowser's html parsing
gave me an idea.

What if we make a mangeling script to test the Kolab resistance
against bad kolab formats?

We could the following mangleme port to python
as a basis for thus a script:
http://felinemenace.org/~nd/htmler.py

Anybody feels like writing one?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041029/124bd34b/attachment.p7s>

From dfaure at klaralvdalens-datakonsult.se  Fri Oct 29 12:59:36 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Fri, 29 Oct 2004 12:59:36 +0200
Subject: Mangle the format?
In-Reply-To: <200410291247.33440.bernhard@intevation.de>
References: <200410291247.33440.bernhard@intevation.de>
Message-ID: <200410291259.36909.dfaure@klaralvdalens-datakonsult.se>

On Friday 29 October 2004 12:47, Bernhard Reiter wrote:
> The recent HTML mangeling tests
> that turned up bugs in basically all webbrowser's html parsing
> gave me an idea.
> 
> What if we make a mangeling script to test the Kolab resistance
> against bad kolab formats?
> 
> We could the following mangleme port to python
> as a basis for thus a script:
> http://felinemenace.org/~nd/htmler.py
> 
> Anybody feels like writing one?

XML isn't like HTML, it's easy to parse safely. And there's no rendering involved.
I don't think there's much point in trying broken XML on parsers.
If you want to send malicious emails that crash people's mailers, you'd have more
chances with HTML-emails IMHO :)

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klar??lvdalens Datakonsult AB, Platform-independent software solutions



From reinhold at kainhofer.com  Fri Oct 29 13:04:57 2004
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri, 29 Oct 2004 13:04:57 +0200
Subject: Mangle the format?
In-Reply-To: <200410291247.33440.bernhard@intevation.de>
References: <200410291247.33440.bernhard@intevation.de>
Message-ID: <200410291305.00065.reinhold@kainhofer.com>

On Friday 29 October 2004 12:47, Bernhard Reiter wrote:
> The recent HTML mangeling tests
> that turned up bugs in basically all webbrowser's html parsing
> gave me an idea.
>
> What if we make a mangeling script to test the Kolab resistance
> against bad kolab formats?
>
> We could the following mangleme port to python
> as a basis for thus a script:
> http://felinemenace.org/~nd/htmler.py
>
> Anybody feels like writing one?

Although off-topic here, we could certainly need such a script for bad 
iCalendar files. I know a few examples of (valid) iCalendar files, which 
crash libical. Thinking of what bad iCalendar files might do to libical gives 
me the shiver ;-)

Cheers,
Reinhold
-------------- 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/20041029/948e1edc/attachment.sig>

From bo at thorsen-consulting.dk  Fri Oct 29 15:09:58 2004
From: bo at thorsen-consulting.dk (Bo Thorsen)
Date: Fri, 29 Oct 2004 15:09:58 +0200
Subject: Mangle the format?
In-Reply-To: <200410291305.00065.reinhold@kainhofer.com>
References: <200410291247.33440.bernhard@intevation.de>
	<200410291305.00065.reinhold@kainhofer.com>
Message-ID: <200410291510.03674.bo@thorsen-consulting.dk>

On Friday 29 October 2004 13:04, Reinhold Kainhofer wrote:
> On Friday 29 October 2004 12:47, Bernhard Reiter wrote:
> > The recent HTML mangeling tests
> > that turned up bugs in basically all webbrowser's html parsing
> > gave me an idea.
> >
> > What if we make a mangeling script to test the Kolab resistance
> > against bad kolab formats?
> >
> > We could the following mangleme port to python
> > as a basis for thus a script:
> > http://felinemenace.org/~nd/htmler.py
> >
> > Anybody feels like writing one?
>
> Although off-topic here, we could certainly need such a script for bad
> iCalendar files. I know a few examples of (valid) iCalendar files,
> which crash libical. Thinking of what bad iCalendar files might do to
> libical gives me the shiver ;-)

I'm normally religious about always adding regression test suites, so I 
can only agree to this :-)

And with shared folders, it's pretty easy for someone to store an odd iCal 
or XML file in there - but you can only do that if you have write access 
to the folders. I would agree with David that there are easier ways to 
DOS attack Kontact.

Bo.
-------------- 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/20041029/f5051f22/attachment.sig>

From reinhold at kainhofer.com  Fri Oct 29 16:08:27 2004
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri, 29 Oct 2004 16:08:27 +0200
Subject: Mangle the format?
In-Reply-To: <200410291510.03674.bo@thorsen-consulting.dk>
References: <200410291247.33440.bernhard@intevation.de>
	<200410291305.00065.reinhold@kainhofer.com>
	<200410291510.03674.bo@thorsen-consulting.dk>
Message-ID: <200410291608.29747.reinhold@kainhofer.com>

On Friday 29 October 2004 15:09, Bo Thorsen wrote:
> And with shared folders, it's pretty easy for someone to store an odd iCal
> or XML file in there - but you can only do that if you have write access
> to the folders. I would agree with David that there are easier ways to
> DOS attack Kontact.

Unfortunately, it's not even so much about odd files. 
Currently, even perfectly valid files crash libical. E.g. Apple iCal's ics 
files with a procedure alarm crash libkcal: 
http://bugs.kde.org/show_bug.cgi?id=88840
These are valid calendar files, but since ATTACH;VALUE=URI:... is never 
created by libkcal, we have never really tested it. 

I suppose there are lots of similar combinations out there that crash libkcal, 
but haven't been found yet. An automatic tool to generate random iCalendar 
files would certainly help here.
Anyway, it's completely off-topic here now.

Reinhold

-- 
------------------------------------------------------------------
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/20041029/10fd9940/attachment.sig>

From bernhard at intevation.de  Fri Oct 29 16:13:25 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 29 Oct 2004 16:13:25 +0200
Subject: freebusy annotations
In-Reply-To: <200410271419.50600.dfaure@klaralvdalens-datakonsult.se>
References: <200409282258.46941.martin.konold@erfrakon.de>
	<200410251625.18067.bernhard@intevation.de>
	<200410271419.50600.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410291613.31029.bernhard@intevation.de>

On Wednesday 27 October 2004 14:19, David Faure wrote:
> On Monday 25 October 2004 16:25, Bernhard Reiter wrote:
> > What about notes and tasks folders for which we would require a
> > similiar annotation, but only for reminders (aka alarms).
>
> Notes don't have alarms, do they? They are not incidences.
> Journals are incidences, but well, alarms don't make much sense for them.
> So I think this only applies to calendar and task folders.
> Bernhard: do you agree?

Yes I think this only applies to tasks and events.

> If yes, Martin: please update the concept paper accordingly, IIRC you
> mentionned notes there too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041029/f107f9ae/attachment.p7s>

From dfaure at klaralvdalens-datakonsult.se  Fri Oct 29 16:37:52 2004
From: dfaure at klaralvdalens-datakonsult.se (David Faure)
Date: Fri, 29 Oct 2004 16:37:52 +0200
Subject: RFC: Splitting the UID concept of tasks and events
In-Reply-To: <200410290238.14304.steffen@klaralvdalens-datakonsult.se>
References: <200410281234.29457.bo@thorsen-consulting.dk>
	<200410290238.14304.steffen@klaralvdalens-datakonsult.se>
Message-ID: <200410291638.11954.dfaure@klaralvdalens-datakonsult.se>

On Friday 29 October 2004 02:38, Steffen Hansen wrote:
> On Thursday 28 October 2004 12:34, Bo Thorsen wrote:
> > Hi all,
> >
> > I just checked a patch into the KDE client that changes the UID
> > concept a bit for tasks and events (aka incidences).
> [...]
> > - The automatic scheduling code in the server needs to have the same
> > changes - save SID on accepting invitations and searching for SID on
> > updates.
> 
> What does this do to the kolab xml format? Right now we have the UID in 
> the Subject: of the mail used for storage -- that makes it much faster 
> for me to search for a particular event. Can we agree on a header or 
> something for the SID? Like
> 
> X-Kolab-SID:  foobar-4711

Sounds like a good idea.

"SID" is pretty unintuitive to anyone who won't have read the kolab spec first,
how about "X-Kolab-SchedulingID"?

I'm adding support for this now.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
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: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20041029/6a499ebe/attachment.sig>

From bernhard at intevation.de  Fri Oct 29 16:47:53 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 29 Oct 2004 16:47:53 +0200
Subject: RFC: Splitting the UID concept of tasks and events
In-Reply-To: <200410291638.11954.dfaure@klaralvdalens-datakonsult.se>
References: <200410281234.29457.bo@thorsen-consulting.dk>
	<200410290238.14304.steffen@klaralvdalens-datakonsult.se>
	<200410291638.11954.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200410291647.57489.bernhard@intevation.de>

On Friday 29 October 2004 16:37, David Faure wrote:
> On Friday 29 October 2004 02:38, Steffen Hansen wrote:
> > On Thursday 28 October 2004 12:34, Bo Thorsen wrote:
> > > Hi all,
> > >
> > > I just checked a patch into the KDE client that changes the UID
> > > concept a bit for tasks and events (aka incidences).
> >
> > [...]
> >
> > > - The automatic scheduling code in the server needs to have the same
> > > changes - save SID on accepting invitations and searching for SID on
> > > updates.
> >
> > What does this do to the kolab xml format? Right now we have the UID in
> > the Subject: of the mail used for storage -- that makes it much faster
> > for me to search for a particular event. Can we agree on a header or
> > something for the SID?

We also could put both in the subject?
(This header and subject searching really is a cludge, what what can we do.)

(I probably have not grasped everything about the sid concept yet.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041029/a4b48e49/attachment.p7s>