Keep string properties of VCALENDAR

[Aggtaa]

Many different ICAL generators, namely MS Exchange, Google Calendars, Apple Calendar, add string properties to VCALENDAR that should be kept during parsing.

E.g. X-WR-CALNAME is an extremely important string property, as well as X-WR-RELCALID, X-WR-CALDESC, X-PRIMARY-CALENDAR and actually all others.

However, current node-ical contains code that intentionally removes all string properties from VCALENDAR component. See here:

node-ical/ical.js

Line 354 in 4195ab2

// Scan all high level object in curr and drop all strings

What's the point of that removal?

[jens-maus]

This seems to be a quite old change before I took over the project, see here:

4b4a4bb

However, i dunno what the purpose of this change was. Perhaps its time to ditch it if there is a good reason and example ics where we can test it on.

[Aggtaa]

Sure. Here you go:

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:node-ical test
X-WR-TIMEZONE:Europe/Moscow
X-WR-CALDESC:A simple calendar to test node-ical parser
END:VCALENDAR

The simplest calendar that can be. No events at all. Created with Google Calendar web interface.

Available from this url also: https://calendar.google.com/calendar/ical/3bafqi1jabdlhhmbvsr7gf39dg%40group.calendar.google.com/public/basic.ics

Can be tweaked for tests if needed.

[Aggtaa]

What's interesting is that radicale generates iCal with these properties instead:

X-WR-CALDESC;VALUE=TEXT:test description
X-WR-CALNAME;VALUE=TEXT:test 2

that result in object properties that are not being deleted.

        "WR-CALDESC": {
                "params": {
                        "VALUE": "TEXT"
                },
                "val": "test description"
        },
        "WR-CALNAME": {
                "params": {
                        "VALUE": "TEXT"
                },
                "val": "test 2"
        },

They are pain to access as export type CalendarResponse = Record<string, CalendarComponent>; and those two are obviously of not CalendarComponent type, but thats another topic, I guess.

[twalling]

We've commented out that delete step in a fork because we needed the string properties. In our case we simply wanted the title of the calendar which is defined as:

X-WR-CALNAME:Holidays in United States

see:
https://en.wikipedia.org/wiki/ICalendar

I can confirm that google's ICS output outputs these extensions like so:

X-WR-CALNAME:Holidays in United States
X-WR-TIMEZONE:UTC
X-WR-CALDESC:Holidays and Observances in United States

[twalling]

@jens-maus looks like that change was made to keep pace with the original project (non-node) version of this library.

peterbraden/ical.js#38

I wish there was a discussion of it in either project. It's hard to see what the reasoning was and there are useful properties one misses out on because of it.

Maybe I could submit a PR to make it optional behavior?