[calsify] Re: JSCalendar, iCalendar, and the calext charter

[Tim Hare <[e-mail]>]

I am also a "seasoned" consumer of iCalendar, and sometime participant in this process (I one wrote an XSLT transform for xcalender to iCalendar, but the format I used for xcalendar was not adopted).   I would not like JSCalendar to replace iCalendary for a simple reason:  JSCalendar requires Javascript - and while Javascript is pretty ubiquitous,  it is also possible that a device might not have enough compute power or memory to run a Javascript engine, while still having the ability to parse an iCalendar text file.
 
Tim Hare
Interested Bystander, Non-Inc.

> On 04/20/2025 7:36 PM CDT Ben Fortuna <[e-mail]> wrote:
>  
>  
> As a seasoned consumer of the iCalendar specification, I am inclined to express an opinion here.
>  
> The success of (parts of) iCalendar should not be underestimated. One might argue it's one of the most widely adopted specifications - approaching the  ubiquity of email! This does not happen easily, as demonstrated by the failure of many attempts to replace or extend such ubiquitous specifications.
>  
> For example, the resistance to Google's proposal to add AMP to emails [1] should be fair warning to anyone contemplating similar changes to established specifications.
>  
> It seems the suggestion here is that JSCalendar is an evolution of iCalendar, but I would argue it is not just iCalendar v5, it is a clear and distinct alternative format for some (not all!) use-cases.
>  
> The JSCalendar format is clearly catering to a world-view of REST-ful APIs as the basis for client-server and server-server communications. But whilst this may be an established world-view currently, it cannot be assumed this is what the landscape will look like 10, 20, or even 5 years from now.
>  
> Even now there is a resurgence of other approaches to application design (e.g. HATEOAS, htmx, etc.), that don't subscribe to the model of JSON APIs, but rather put HTML at the centre. And if HTML is the lingua franca of the Internet, then it would make sense to look at other formats such as JSON-LD as the logical evolution of iCalendar.
>  
> I am not suggesting there is no place for JSCalendar, but rather that it cannot replace iCalendar for all the current (and future) use-cases, and so should not be assumed as a replacement for iCalendar.
>  
> As custodians of the iCalendar specifications I would further implore the working group to encourage more opinions from beyond the membership to expand the understanding of how these specifications are used to shape the landscape of interoperability between existing and future calendaring use-cases.
>  
> [1] - https://news.ycombinator.com/item?id=43725865
>  
> --
> Ben Fortuna
>  
>  
> https://www.linkedin.com/in/benfortuna | https://github.com/benfortuna
>  
>  
> On Monday, April 21st, 2025 at 2:11 AM, Michael Douglass <[e-mail]> wrote:
> 
> > 
> > Rather than address individual points I'd like to address the different scenarios raised here:
> > 
> >  
> > 
> > > * Should JSCalendar replace iCalendar? If so, why does the working group continue to publish iCalendar extensions?
> > > * Should JSCalendar and iCalendar co-exist independently and only share a common core of calendaring elements? If so, what is that core and how do we deal with existing differences within that core?
> > > * Should JSCalendar and iCalendar be fully compatible, providing two different representations of the same calendaring data model? If so, how do we deal with all the existing differences between the two formats?
> > > * Is JSCalendar primarily meant for new calendaring APIs, such as JMAP for Calendars, or should JSCalendar also be used with CalDAV? Are services expected to schedule and exchange calendaring data with JSCalendar, or should that be left to iTIP and iMIP using iCalendar?
> > > * Last but not least, what are your main use cases for JSCalendar? If you haven't implemented JSCalendar, why not? If you did, how did you deal with semantic gaps or differences?
> > > 
> > It's probably a good approach to envisage JSCalendar ultimately replacing iCalendar. However - that really requires showing how that can be done without causing turmoil. No provider is going to take the risk of breaking something that currently works (mostly) unless there's a really good reason for doing so and if it's shown that there is a smooth transition path.
> > 
> > It doesn't really matter how it's delivered. You could imagine only JSCalendar for JMAP for Calendars but you still have to send and receive from clients that only support iCalendar whether it's iMip or CalDAV or Exchange.
> > 
> > It's nice to imagine that a new representation in some way opens to door to all sorts of new functionality. The reality is that almost no extensions to iCalendar have shown up in the main services and - unless they perceive some real value in doing so - it's unlikely they really want to move to JSCalendar.
> > 
> > The answer to the first scenario "Should JSCalendar replace iCalendar?" really depends on the big providers and my guess is they won't answer the question - we can only guess.
> > 
> > As I've said before - my belief is that the best hope of getting JSCalendar accepted is to SHOW that a transition can be painless. That means in the short/medium term - making JSCalendar and iCalendar fully compatible and demonstrating that scheduling between parties using a mix of servers and representations works as well as it does now.
> > 
> > Most of the differences you mention at the start (locations, status etc) can be ironed out. CalDAV can deliver JSCalendar now - that's how I test my own conversions. iMip is a problem - but I guess that can be resolved by adding JSCalendar to the mix. It needs a significant amount of testing with the maximum mix of services and clients. That needs some significant engagement from the developers of the standards and would benefit greatly from the engagement of the major providers but I don't think that's going to happen on this list.
> > 
> > I think there also needs to be some real attempt to show what value such a transition has - even if it's painless
> > 
> > Absent all that I think the rest is all pretty much academic.
> > 
> >  
> > 
> > On 4/17/25 08:25, Robert Stepanek wrote:
> > 
> > > [This mail is long. Still, if JSCalendar and iCalendar is of concern to you, I hope you will find time to read and reply. Thank you.]
> > >  
> > > At IETF 121 in Dublin I had presented the status of draft-ietf-calext-jscalendar-icalendar https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar/ and highlighted that JSCalendar and iCalendar have much in common but differ in some areas. That these differences exist and that I cannot clearly explain the working group's stance on how to deal with them, suggested to me that we need to clarify this. In this mail, I would like to continue that discussion.
> > >  
> > > Before I get back to where we left off at IETF 121, I'll describe the challenges I currently face when mapping between JSCalendar and iCalendar. Broadly speaking, differences between JSCalendar and iCalendar fall into two categories:
> > > 1. One format has richer semantics than the other. For example, the VALARM component in iCalendar has more properties than the Alert object, but all properties of an Alert object have counterparts in a VALARM. Mapping between the two formats in this case means to either omit the nonconvertible properties and accept the loss, or to use conversion-specific properties. The latter has the drawback that this is about as ergonomic as mixing XML and JSON in a single document.
> > > 2. Both formats have the same elements but their semantics differ. For example, multiple LOCATION properties and VLOCATION components of a PARTICIPANT conflict with the single-valued Participant locationId. Multiple VSTATUS components and substate values of a VTODO conflict with the single-valued progress property of a Task or Participant. The JSCalendar localization property and the LANGUAGE parameter aren't really the same thing. Also, how multiple scheduling methods in JSCalendar relate to iCalendar scheduling still isn't clear to me. Mapping between the two formats in this case is not straight-forward.
> > > These examples are not exhaustive. A complete list of unsupported elements is listed in the appendix https://www.ietf.org/archive/id/draft-ietf-calext-jscalendar-icalendar-12.html#name-discrepancies-between-icale of my I-D. The examples throughout that document also highlight how one frequently must use conversion-specific properties to preserve data without loss, which demonstrates differences of category 1.
> > >  
> > > The semantic differences in category 2 are particularly concerning. The VLOCATION and PARTICIPANT components were defined in RFC 9073 https://www.rfc-editor.org/rfc/rfc9073 after JSCalendar was published, and the VSTATUS component is defined in soon to be published draft-ietf-calext-ical-tasks https://datatracker.ietf.org/doc/draft-ietf-calext-ical-tasks/! These gaps suggest that we as a working group, and I as a reviewer, haven't lived up to the working group's charter. The charter requires that working group documents "must include a representation in both formats, and define a robust mapping" and "are expected to be backwards-compatible with the existing standards".
> > >  
> > > Now I get back to our discussion at IETF 121 in Dublin. Back then I had proposed that we should recharter the working group and that JSCalendar and iCalendar extensions just "should include a representation in both formats". The outcome of the discussion was that this isn't desired and that the current charter requirements are met, as long as one can somehow preserve the "core" elements during conversion.
> > >  
> > > I do not agree with the outcome of that discussion: I still think that it conflicts with the charter, that this gap between the charter and the working group's document contents is confusing to anyone considering to use JSCalendar, that this "core" would in any case need to be precisely defined, and that until all that is resolved the semantic differences are likely to become worse with any future work on iCalendar and JSCalendar.
> > >  
> > > Rather than asking to recharter, I suggest we first come to a common understanding in this working what our goals for JSCalendar and iCalendar are. This should guide us in deciding how to deal with existing differences, as well as what to expect from future contributions. To start this discussion, let's align on the following questions:
> > > * Should JSCalendar replace iCalendar? If so, why does the working group continue to publish iCalendar extensions?
> > > * Should JSCalendar and iCalendar co-exist independently and only share a common core of calendaring elements? If so, what is that core and how do we deal with existing differences within that core?
> > > * Should JSCalendar and iCalendar be fully compatible, providing two different representations of the same calendaring data model? If so, how do we deal with all the existing differences between the two formats?
> > > * Is JSCalendar primarily meant for new calendaring APIs, such as JMAP for Calendars, or should JSCalendar also be used with CalDAV? Are services expected to schedule and exchange calendaring data with JSCalendar, or should that be left to iTIP and iMIP using iCalendar?
> > > * Last but not least, what are your main use cases for JSCalendar? If you haven't implemented JSCalendar, why not? If you did, how did you deal with semantic gaps or differences?
> > >  
> > > I very much look forward your replies,
> > > Robert
> > >  
> > > P.S.: The same questions also apply for JSContact and vCard, but I am much less concerned about them for now. Their current differences are negligible, so these documents meet the current charter's requirements. Of course, as soon as any new extension to JSContact or vCard is proposed, we will have to be clear how to deal with them.
> > > 
> > > 
> > > _______________________________________________
> > > calsify mailing list -- [e-mail] mailto:[e-mail]
> > > To unsubscribe send an email to [e-mail] mailto:[e-mail]
> > > 
> > 
> _______________________________________________
> calsify mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>