From bh at intevation.de  Tue Apr  1 18:52:40 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Tue, 1 Apr 2008 18:52:40 +0200
Subject: [Kolab-devel] RFC: "gender" field in contacts
In-Reply-To: <200804011415.37982.thomas.jarosch@intra2net.com>
References: <200803311922.59868.thomas.jarosch@intra2net.com>
	<200804011148.13531.bh@intevation.de>
	<200804011415.37982.thomas.jarosch@intra2net.com>
Message-ID: <200804011852.43875.bh@intevation.de>

CC to kolab-format at kolab.org because that's where this question should really 
be discussed.  A final decision should be made on that list.

On Tuesday 01 April 2008 14:15, Thomas Jarosch wrote:
> On Tuesday, 1. April 2008 11:48:04 Bernhard Herzog wrote:
> > I think it would be better to use either single letters (m, f) or to
> > spell it out (male, female).  Both are preferable because their meaning
> > is reasonably obvious.  With integers you always have to consult the
> > documentation to figure out what they mean.  To indicate an unspecified
> > gender, leave out the gender element altogether or leave it empty.
>
> That's a good point. "male" and "female" is best as it's consistent
> with the rest of the Kolab format using complete names
> like the recurrence pattern types do.

I've talked about this with Bernhard Reiter and Thomas Arendsen Hein.  They 
both prefer spelling out male or female, too.  An unspecified or unknown 
gender can be indicated by omitting the gender element altogether or by 
leaving it empty.

Do we need other values?

   Bernhard

-- 
Bernhard Herzog                              Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080401/7ccfa6de/attachment.bin

From bernhard at intevation.de  Tue Apr 15 18:22:04 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 15 Apr 2008 18:22:04 +0200
Subject: [Kolab-devel] RFC: "gender" field in contacts
In-Reply-To: <200804011852.43875.bh@intevation.de>
References: <200803311922.59868.thomas.jarosch@intra2net.com>
	<200804011415.37982.thomas.jarosch@intra2net.com>
	<200804011852.43875.bh@intevation.de>
Message-ID: <200804151822.13379.bernhard@intevation.de>

Joon,
are you okay with the proposal to fix the <gender> element tag
in the format specification?

diff -u -u -0 -r1.16 contacts.sgml
--- contacts.sgml       16 Nov 2006 22:34:55 -0000      1.16
+++ contacts.sgml       15 Apr 2008 16:19:57 -0000
@@ -75,0 +76,3 @@
+<para>gender can be empty or is one of male or female.
+</para>
+

On Tuesday 01 April 2008 18:52, Bernhard Herzog wrote:
> CC to kolab-format at kolab.org because that's where this question should
> really be discussed.  A final decision should be made on that list.
>
> On Tuesday 01 April 2008 14:15, Thomas Jarosch wrote:
> > On Tuesday, 1. April 2008 11:48:04 Bernhard Herzog wrote:
> > > I think it would be better to use either single letters (m, f) or to
> > > spell it out (male, female).  Both are preferable because their meaning
> > > is reasonably obvious.  With integers you always have to consult the
> > > documentation to figure out what they mean.  To indicate an unspecified
> > > gender, leave out the gender element altogether or leave it empty.
> >
> > That's a good point. "male" and "female" is best as it's consistent
> > with the rest of the Kolab format using complete names
> > like the recurrence pattern types do.
>
> I've talked about this with Bernhard Reiter and Thomas Arendsen Hein.  They
> both prefer spelling out male or female, too.  An unspecified or unknown
> gender can be indicated by omitting the gender element altogether or by
> leaving it empty.
>
> Do we need other values?

The main questions for more values is:
Do we need to make a distinction between unknown and unspecified? 
As far as I can see: We do not need those two values and could wait
if a real use case pops up.

Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080415/c0fca1e9/attachment.bin

From bernhard at intevation.de  Tue Apr 15 18:26:49 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 15 Apr 2008 18:26:49 +0200
Subject: Declaring a new folder type and format for Horde preferences
In-Reply-To: <87fxul5tio.fsf@home.pardus.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200803171151.52125.bernhard@intevation.de>
	<87fxul5tio.fsf@home.pardus.de>
Message-ID: <200804151826.51005.bernhard@intevation.de>

On Thursday 20 March 2008 16:01, Gunnar Wrobel wrote:
> Bernhard Reiter <bernhard at intevation.de> writes:
> > On Friday 14 March 2008 16:57, Gunnar Wrobel wrote:
> >> Concerning the "Preferences" I'm hesitating though: Why shouldn't
> >> Kontact for example be able to store configuration options in there
> >> too?
> >
> > I think we had a couple of drawbacks mentioned already,
> > this is why a consistant writeup of the consideration would be quite
> > useful.
>
> I made this Horde-only now. So I'm not certain if any elaborate
> documentation makes much sense here. Or do you mean a writeup of the
> presence of custom folder in general?

I've meant the idea how to save configuration where and your solution.
We could learn something about where to save configuration for other clients 
as well. We should try to save our discussed knowledge as good as possible.

IMO design criteria for such a configuration place would be
that some client would want to have several configuration and also
there are a lot of configuration values that should be the same across clients 
of same or different type.

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080415/c3f13e13/attachment.bin

From joon at radleys.co.za  Tue Apr 15 21:56:37 2008
From: joon at radleys.co.za (Joon Radley)
Date: Tue, 15 Apr 2008 21:56:37 +0200
Subject: [Kolab-devel] RFC: "gender" field in contacts
In-Reply-To: <200804151822.13379.bernhard@intevation.de>
References: <200803311922.59868.thomas.jarosch@intra2net.com>	<200804011415.37982.thomas.jarosch@intra2net.com>	<200804011852.43875.bh@intevation.de>
	<200804151822.13379.bernhard@intevation.de>
Message-ID: <006001c89f32$d32c82f0$798588d0$@co.za>

Hi all,

> +<para>gender can be empty or is one of male or female.
> +</para>

I have no problem with proposed change to the <gender> tag. 

Best Regards

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

> -----Original Message-----
> From: kolab-format-bounces at kolab.org [mailto:kolab-format-
> bounces at kolab.org] On Behalf Of Bernhard Reiter
> Sent: Tuesday, April 15, 2008 6:22 PM
> To: kolab-format at kolab.org
> Cc: Joon Radley
> Subject: Re: [Kolab-devel] RFC: "gender" field in contacts
> 
> Joon,
> are you okay with the proposal to fix the <gender> element tag in the
> format specification?
> 
> diff -u -u -0 -r1.16 contacts.sgml
> --- contacts.sgml       16 Nov 2006 22:34:55 -0000      1.16
> +++ contacts.sgml       15 Apr 2008 16:19:57 -0000
> @@ -75,0 +76,3 @@
> +<para>gender can be empty or is one of male or female.
> +</para>
> +
> 
> On Tuesday 01 April 2008 18:52, Bernhard Herzog wrote:
> > CC to kolab-format at kolab.org because that's where this question
> should
> > really be discussed.  A final decision should be made on that list.
> >
> > On Tuesday 01 April 2008 14:15, Thomas Jarosch wrote:
> > > On Tuesday, 1. April 2008 11:48:04 Bernhard Herzog wrote:
> > > > I think it would be better to use either single letters (m, f) or
> > > > to spell it out (male, female).  Both are preferable because
> their
> > > > meaning is reasonably obvious.  With integers you always have to
> > > > consult the documentation to figure out what they mean.  To
> > > > indicate an unspecified gender, leave out the gender element
> altogether or leave it empty.
> > >
> > > That's a good point. "male" and "female" is best as it's consistent
> > > with the rest of the Kolab format using complete names like the
> > > recurrence pattern types do.
> >
> > I've talked about this with Bernhard Reiter and Thomas Arendsen Hein.
> > They both prefer spelling out male or female, too.  An unspecified or
> > unknown gender can be indicated by omitting the gender element
> > altogether or by leaving it empty.
> >
> > Do we need other values?
> 
> The main questions for more values is:
> Do we need to make a distinction between unknown and unspecified?
> As far as I can see: We do not need those two values and could wait if
> a real use case pops up.
> 
> Bernhard
> 
> 
> --
> Managing Director - Owner: www.intevation.net       (Free Software
> Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-
> Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From bernhard at intevation.de  Fri Apr 18 11:18:32 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 18 Apr 2008 11:18:32 +0200
Subject: [Kolab-devel] RFC: "gender" field in contacts
In-Reply-To: <006001c89f32$d32c82f0$798588d0$@co.za>
References: <200803311922.59868.thomas.jarosch@intra2net.com>
	<200804151822.13379.bernhard@intevation.de>
	<006001c89f32$d32c82f0$798588d0$@co.za>
Message-ID: <200804181118.36975.bernhard@intevation.de>

On Tuesday 15 April 2008 21:56, Joon Radley wrote:
> > +<para>gender can be empty or is one of male or female.
> > +</para>
>
> I have no problem with proposed change to the <gender> tag.

Committed, scheduled for 2.0rc7.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080418/a91a6551/attachment.bin

From bernhard at intevation.de  Fri Apr 18 11:25:55 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 18 Apr 2008 11:25:55 +0200
Subject: 2.0rc7 -> 2.0 in two weeks
Message-ID: <200804181125.56872.bernhard@intevation.de>

I have checked in a revision mark and a clarification about the sensitivity 
(that slipped the 2.0rc5 editing cycle). Thus we are ready to put out 2.0rc7
which we will do as soon as we get around (in the next days).

If no-one raises a serious objection, 
we will declare 2.0rc7 to be 2.0 after about 2 weeks.

This is overdue in my opinion. 
Given that several clients sucessfully implement the storage format
for many years I believe the format in itself is a success
and the version number should reflect the actual stability of the 
specification.

Of course: We will improve the specification at some point, 
but this should not be under the 2.0 label. 
We could issue fixes 2.0.1 and work on 2.1 if we like.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080418/b4a2a227/attachment.bin

From thomas.jarosch at intra2net.com  Fri Apr 18 11:51:32 2008
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Fri, 18 Apr 2008 11:51:32 +0200
Subject: 2.0rc7 -> 2.0 in two weeks
In-Reply-To: <200804181125.56872.bernhard@intevation.de>
References: <200804181125.56872.bernhard@intevation.de>
Message-ID: <200804181151.32480.thomas.jarosch@intra2net.com>

Hello Bernhard,

On Friday, 18. April 2008 11:25:55 Bernhard Reiter wrote:
> I have checked in a revision mark and a clarification about the sensitivity
> (that slipped the 2.0rc5 editing cycle). Thus we are ready to put out
> 2.0rc7 which we will do as soon as we get around (in the next days).
>
> If no-one raises a serious objection,
> we will declare 2.0rc7 to be 2.0 after about 2 weeks.
>
> This is overdue in my opinion.
> Given that several clients sucessfully implement the storage format
> for many years I believe the format in itself is a success
> and the version number should reflect the actual stability of the
> specification.

Thanks for commiting the gender field change!

I'm currently fixing Horde's "categories" handling and noticed that multi 
value fields like "children" don't define a separator. <categories> already 
uses ",", so should we add a generic note that multi value fields
get separated by ',' to be on the safe side?

I'm still wondering about the decision to use a separator for multi value 
fields instead of an own XML tag per value, f.e.

<category>private</category>
<category>company</category>

instead of 

<categories>private, company</categories>

Thomas


From bernhard at intevation.de  Fri Apr 18 15:23:37 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 18 Apr 2008 15:23:37 +0200
Subject: multi value fields (was: 2.0rc7 -> 2.0 in two weeks)
In-Reply-To: <200804181151.32480.thomas.jarosch@intra2net.com>
References: <200804181125.56872.bernhard@intevation.de>
	<200804181151.32480.thomas.jarosch@intra2net.com>
Message-ID: <200804181523.42325.bernhard@intevation.de>

Hi Thomas,

On Friday 18 April 2008 11:51, Thomas Jarosch wrote:
> I'm currently fixing Horde's "categories" handling and noticed that multi
> value fields like "children" don't define a separator. <categories> already
> uses ",", so should we add a generic note that multi value fields
> get separated by ',' to be on the safe side?

we should make a list of multi value fields first.
IMO I am unsure about the nature of <children>, this could contain other
statements about the children like: "Yes, three. All boys".

> I'm still wondering about the decision to use a separator for multi value
> fields instead of an own XML tag per value, f.e.
>
> <category>private</category>
> <category>company</category>
>
> instead of
>
> <categories>private, company</categories>

According to our CVS history, this was in there from the beginning.
I don't know who added it, maybe Bo.
For Categories, it might just have been simpler.

Best,
Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080418/c3b7422f/attachment.bin

From joon at radleys.co.za  Fri Apr 18 15:43:37 2008
From: joon at radleys.co.za (Joon Radley)
Date: Fri, 18 Apr 2008 15:43:37 +0200
Subject: 2.0rc7 -> 2.0 in two weeks
In-Reply-To: <200804181125.56872.bernhard@intevation.de>
References: <200804181125.56872.bernhard@intevation.de>
Message-ID: <002401c8a15a$37ce61a0$a76b24e0$@co.za>

Hi Bernhard,

> If no-one raises a serious objection,
> we will declare 2.0rc7 to be 2.0 after about 2 weeks.

This is excellent news.

Will he version number in the XML generated objects have to change to 2.0 or
will it stay 1.0. I think the changes that where made where more for
clarification that actual format changes.

Best Regards

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

> -----Original Message-----
> From: kolab-format-bounces at kolab.org [mailto:kolab-format-
> bounces at kolab.org] On Behalf Of Bernhard Reiter
> Sent: Friday, April 18, 2008 11:26 AM
> To: kolab-format at kolab.org
> Subject: 2.0rc7 -> 2.0 in two weeks
> 
> I have checked in a revision mark and a clarification about the
> sensitivity (that slipped the 2.0rc5 editing cycle). Thus we are ready
> to put out 2.0rc7 which we will do as soon as we get around (in the
> next days).
> 
> If no-one raises a serious objection,
> we will declare 2.0rc7 to be 2.0 after about 2 weeks.
> 
> This is overdue in my opinion.
> Given that several clients sucessfully implement the storage format for
> many years I believe the format in itself is a success and the version
> number should reflect the actual stability of the specification.
> 
> Of course: We will improve the specification at some point, but this
> should not be under the 2.0 label.
> We could issue fixes 2.0.1 and work on 2.1 if we like.
> 
> Best,
> Bernhard
> 
> --
> Managing Director - Owner: www.intevation.net       (Free Software
> Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-
> Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From bernhard at intevation.de  Fri Apr 18 17:12:43 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 18 Apr 2008 17:12:43 +0200
Subject: 2.0rc7 -> 2.0 in two weeks
In-Reply-To: <002401c8a15a$37ce61a0$a76b24e0$@co.za>
References: <200804181125.56872.bernhard@intevation.de>
	<002401c8a15a$37ce61a0$a76b24e0$@co.za>
Message-ID: <200804181712.47995.bernhard@intevation.de>

Hi Joon,

On Friday 18 April 2008 15:43, Joon Radley wrote:
> > If no-one raises a serious objection,
> > we will declare 2.0rc7 to be 2.0 after about 2 weeks.
>
> This is excellent news.
>
> Will he version number in the XML generated objects have to change to 2.0
> or will it stay 1.0. I think the changes that where made where more for
> clarification that actual format changes.

a good question, you are refering to

  1.2. XML format description
[..]
  The version attribute denotes the version of this specification. Until a 
  stable version is released, the number "1.0" is used.

You are right: We should clarify this.

Hmmm, actually there were a few minor changes over the time, 
so I think it would be reasonable to stick with the idea of using 2.0 now.
Otherwise we could decouple the version number of the type from the version
number of the specification and just keep the "1.0" until we hit an 
incompatible change. I tend to at least upgrade to "2.0". Shouldn't be a 
large problem as implementor would have considered this "feature" for a 
while.

What do you all think?

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080418/4bdc96f8/attachment.bin

From bernhard at intevation.de  Wed Apr 30 16:24:18 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 30 Apr 2008 16:24:18 +0200
Subject: 2.0rc7 -> 2.0 in two weeks
In-Reply-To: <200804181712.47995.bernhard@intevation.de>
References: <200804181125.56872.bernhard@intevation.de>
	<002401c8a15a$37ce61a0$a76b24e0$@co.za>
	<200804181712.47995.bernhard@intevation.de>
Message-ID: <200804301624.27805.bernhard@intevation.de>

Hi Joon,

On Friday 18 April 2008 17:12, Bernhard Reiter wrote:
> Hmmm, actually there were a few minor changes over the time,
> so I think it would be reasonable to stick with the idea of using 2.0 now.
> Otherwise we could decouple the version number of the type from the version
> number of the specification and just keep the "1.0" until we hit an
> incompatible change. I tend to at least upgrade to "2.0". Shouldn't be a
> large problem as implementor would have considered this "feature" for a
> while.
>
> What do you all think?

we (Ludwig) did a quick test with
KDE Kolab Client Proko2, enterprise35, Horde and Toltec 2.2.0 (we happend to 
have this on one testing machine).

events:
s/<event version="1.0" >/<event version="2.0" >
contacts:
s/<contact version=1.0" >/<contact version="2.0">

the only problem was there with Toltec which did not display the objects.
Joon, can you confirm?

If so, this would be an argument for keeping "1.0" in the upcoming 2.0 
spec. :)

Best,
Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20080430/9ea17123/attachment.bin

From joon at radleys.co.za  Wed Apr 30 18:47:24 2008
From: joon at radleys.co.za (Joon Radley)
Date: Wed, 30 Apr 2008 18:47:24 +0200
Subject: 2.0rc7 -> 2.0 in two weeks
In-Reply-To: <200804301624.27805.bernhard@intevation.de>
References: <200804181125.56872.bernhard@intevation.de>	<002401c8a15a$37ce61a0$a76b24e0$@co.za>	<200804181712.47995.bernhard@intevation.de>
	<200804301624.27805.bernhard@intevation.de>
Message-ID: <003b01c8aae1$e11dcfd0$a3596f70$@co.za>

Hi Bernhard,

We do a version check on the Kolab-XML and any version we do not understand
Toltec rejects. I thought that was the whole point of putting the version in
the Kolab-XML object :)

Best Regards

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

> -----Original Message-----
> From: kolab-format-bounces at kolab.org [mailto:kolab-format-
> bounces at kolab.org] On Behalf Of Bernhard Reiter
> Sent: Wednesday, April 30, 2008 4:24 PM
> To: kolab-format at kolab.org
> Cc: ludwig at intevation.de; Joon Radley
> Subject: Re: 2.0rc7 -> 2.0 in two weeks
> 
> Hi Joon,
> 
> On Friday 18 April 2008 17:12, Bernhard Reiter wrote:
> > Hmmm, actually there were a few minor changes over the time, so I
> > think it would be reasonable to stick with the idea of using 2.0 now.
> > Otherwise we could decouple the version number of the type from the
> > version number of the specification and just keep the "1.0" until we
> > hit an incompatible change. I tend to at least upgrade to "2.0".
> > Shouldn't be a large problem as implementor would have considered
> this
> > "feature" for a while.
> >
> > What do you all think?
> 
> we (Ludwig) did a quick test with
> KDE Kolab Client Proko2, enterprise35, Horde and Toltec 2.2.0 (we
> happend to have this on one testing machine).
> 
> events:
> s/<event version="1.0" >/<event version="2.0" >
> contacts:
> s/<contact version=1.0" >/<contact version="2.0">
> 
> the only problem was there with Toltec which did not display the
> objects.
> Joon, can you confirm?
> 
> If so, this would be an argument for keeping "1.0" in the upcoming 2.0
> spec. :)
> 
> Best,
> Bernhard
> --
> Managing Director - Owner: www.intevation.net       (Free Software
> Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-
> Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner