[calsify] Re: Versioning JSCalendar?

[Phillip Hallam-Baker <[e-mail]>]

My take on versioning is that:

1) We should do the same thing for JSContact and JSCalendar because we are
going to be in a world of hurt otherwise.

2) We are not so deeply dug in on JSCalendar that we are absolutely past
the change point, but I don't think changing JSCalendar in substance is
necessary.

3) For a protocol, a change in the major version number is advertising that
this is a breaking change, legacy applications can't expect to make sense
of the data at all. Upping the major version number should be something
that is exceptionally rare. In fact it should be so rare that maybe you
should be changing the media type.

4) For a protocol, a change in the minor version number is most useful as a
negotiation mechanism. Telling a legacy client that there is some new
functionality in use that they might like to be using, letting people pick
clients that are up to date.

5) The two protocols are going to interact because when Alice sends a
JSCalendar invitation to Bob, her client is going to go to Bob's JSContact
to look at the available delivery options. And those should have the
ability to specify which versions Bob accepts. Don't have to do intervals
here, just the highest version number accepted for each major version so
[1.3, 2.6, 3.0]

Seems that knowing that this is a version x.4 appointment might be a useful
thing for an x.3 client to know even if it can't act on that knowledge.


I have been quiet here for a while but I have been working hard on things
that I think might be relevant in a very short while. Consider the
following scenario:

* Alice and Bob have exchanged JSContact information that contain a public
key encryption credential for each other.
* Alice is sending Bob a meeting invite in JSCalendar format

Now ignoring for the time being the precise transport protocol used to get
the invite from Alice to Bob, wouldn't we want to be encrypting it end to
end?

So, we might have a list of the encapsulation formats supported [ OpenPGP,
S/MIME, JOSE ]


Given that we are in XMLville, I am thinking JOSE is the format that is
going to be most fluent but others may have different ideas, especially if
they have already written the code.




On Tue, Jan 20, 2026 at 5:03 AM 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]
>