Subject: [Ietf-calsify] VERSION value in iCal-Basic

From: Doug at Royer.com (Doug Royer)
Date: Sat Jun 18 21:08:56 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050618/945b0d46/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sun Jun 19 01:52:34 2005

Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> It is by belief that iCal-Basic is compatible to implementations.
> That is the changes are clarifying existing components, properties,
> and parameters and reduces the number of them.
>
> I believe that it is possible for an RFC-2445 implementation
> to have generated an iCal-Basic object (except new properties
> which it would ignore per 2445).
>
> So, I am proposing that iCal-Basic have a VERSION value
> of:
>
> 	VERSION:2.0;2.1
>
> Specifying that it is newer (2.1) and can be read by existing (2.0)
> parsers and implementations.
>
> There is no change to the 2445 VERSION property needed to support this
> value. The existing 2445 VERSION property supports a range
> of VERSION property values.

And since calsify is about using only what is supported by most 
implementations: How many implementations actually support this range?  My 
guess is approximately 0. 
I wonder how implementations behave when they encounter such a VERSION? If 
they accept it and parse it, then fine. But I suspect that there are 
implementations out there that compare the version string with "2.0" and 
produce an error message otherwise. This should not happen, of course.

At least libkcal (KDE's calendar library including support for iCalendar) 
fails with such a VERSION...
Mozilla calendar seems to ignore the VERSION altogether (but hangs while 
importing such a file, no idea what's the exact reason).
And Evolution also ignores the VERSION completely (i.e. if the version is 
"4.0", evolution also imports it just fine... Which it shouldn't, I guess?)

So far, there was no other calendar version that tried to be compatible with 
2445, so this was a working approach, but with calsify things change...

Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], 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.osafoundation.org/pipermail/ietf-calsify/attachments/20050619/90a3c8a6/attachment.pgp

---

From: Doug at royer.com (Doug Royer)
Date: Sun Jun 19 13:17:31 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050619/1f246bf3/smime.bin

---

From: Doug at royer.com (Doug Royer)
Date: Sun Jun 19 13:17:35 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050619/f122ed27/smime.bin