[calsify] Re: Versioning JSCalendar?

[Mauro De Gennaro <[e-mail]>]

Hi Robert,

I’m generally in favour of aligning JSCalendar with JSContact here: introducing an explicit version property and requiring implementations to ignore but preserve unknown elements both seem like sensible steps to me. 

Regarding the bad experience with iCalendar versioning: I don’t know all the historical details of why the iCalendar version was never updated and effectively stayed at “2.0” despite changes over time. As a comparison, in vCard we do have versions 2.1, 3.0, and 4.0. If a parser implements the latest version, explicit version numbers are often not strictly necessary for parsing older cards, as the version can usually be inferred from the properties and parameters in use. However, version numbers become important when a parser receives data from a version it does not support. In that case, the version property is important to detect incompatibility and avoid misinterpreting the data.

One open question I do have, and would like to discuss further, is how to handle changes in data types for properties that are already known to the parser. For example, imagine that in a hypothetical JSCalendar v3 the “colour” property changes from a String to an object like Colour { red: Int, green: Int, blue: Int }
This would clearly break older parsers that expect a String. My suggestion would be that unknown value types for known properties should be preserved in the same way as unknown properties are today, effectively treating them as opaque data rather than trying (and failing) to interpret them. 


Best,
Mauro

> On 20 Jan 2026, at 07:03, Robert Stepanek <rsto=[e-mail]> wrote:
> 
> Related to Daniel Migault's review feedack <https://mailarchive.ietf.org/arch/msg/calsify/hvuh57T5eGrsYPe3eOimDBtJhU0/>, I'm looking for the working group's opinion on if and how to version JSCalendar data. I want to decide before we publish JMAP for Calendars and the new JSCalendar specification.
> 
> Currently, JSCalendar (RFC 8984) does not define versioning. In contrast, JSContact (RFC 9553) does require each Card object to have a "version" property and that value consists of a major and minor version (see Section 1.9 in RFC 9553 <https://www.rfc-editor.org/rfc/rfc9553.html#name-versioning>).
> 
> Related, JSCalendar does not instruct implementations how to deal with unknown elements, except for a few specific cases such as the "Group.entries" or the "Participant.roles" properties. In contrast, JSContact explicitly requires implementations to ignore but preserve unknown elements. The idea is that implementations should be able to deal with JSContact data even if they do not support the minor version that is indicated in the payload (see Section 1.7.4 in RFC 9553 <https://datatracker.ietf.org/doc/html/rfc9553#name-unknown-properties>).
> 
> We originally hadn't defined versioning in JSCalendar because of bad experiences with iCalendar, which up to today sticks to version "2.0" despite significant changes since RFC 5545. For JSContact, we instead thought we can make versioning work. Time will tell if that will work out in practice, but at least the JSContact IANA registry policy clearly defines that every change requires at least to bump the minor version, if not the major version. We are right now doing this in draft-ietf-calext-jscontact-uid <https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact-uid/>.
> 
> Orthogonal to versions, JMAP allows to negotiate which properties are supported using extensions, but that only is possible in context of that transport protocol.
> 
> I'm leaning towards aligning JSCalendar versioning with what we have in JSContact, that is: introducing a version property and requiring implementations to preserve unknown elements. But I also know this hasn't proven in practice and it might cause different trouble than not doing any versioning.
> 
> What's your take on this?
> 
> Thanks,
> Robert
> _______________________________________________
> calsify mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]