A simple rule for designing data formats: if you want your data format to declare in-band what its format version is (and you probably do), then you MUST guarantee that the version identifier appears at a relatively fixed position near the top and is parsable with a minimum of effort.
vCalendar 1.0 and its successor iCalendar 2.0 fail here: they require a VERSION property, but don’t mandate that it appear anywhere near the top. iCalendar is even worse, by allowing arbitrary non-standard properties (with parsing rules that differ from vCalendar’s) to appear on the VERSION line. And in both cases the VERSION line can be line-folded, except that the line folding rules are slightly different between the two standards.
I have almost managed to create a file that parses successfully (including VERSION line) as both iCalendar and vCalendar. For example:
BEGIN:VCALENDAR PRODID;ENCODING=QUOTED-PRINTABLE:Something= VERSION:2.0 VERSION:1.0 END:VCALENDAR
contains the line VERSION:2.0, and yet is a perfectly valid vCalendar 1.0 file. (The fact that the line folding examples in the vCalendar spec are wrong doesn’t help either.)
Bah. Don’t do that. What would the harm would have been in saying BEGIN:VCALENDAR[1.0]?
Post a Comment