search

collective / icalendar

icalendar parser library for Python
https://icalendar.readthedocs.io
Other
1k stars 171 forks source link

Mandatory properties are neither enforced nor set to a default #596

Open danielschenk opened 8 months ago

danielschenk commented 8 months ago

According to RFC 5545, every VCAL needs a PRODID and VERSION. If those are not explicitly added, Calendar.to_ical() produces non-conforming output because they are missing.

It could be a deliberate design choice to leave this open. But I wonder, how often do people want to generate invalid output, and shouldn't the library enforce a valid calendar object somehow?

Just some suggestions here.

VERSION

As this library claims to be implementing RFC 5545, I think this should just be 2.0 by default. If you add it again with a different value, that's fine, it will be replaced.

PRODID

What about setting this to something like -//python.collective.icalendar//NONSGML python.collective.icalendar.app.event//EN? (I'm not sure how exactly these strings should be constructed, I just wrote something based on a test case I saw in this repo). Same here, if you add it again with a different value, it will be replaced.

Both of above improvements are fully backwards-compatible, AFAIK. Please let me know your thoughts.

niccokunzmann commented 8 months ago

I would think that is is nice to add a few default properties that make the calendar valid. If you like to create a Pull Request, that would be welcome!

danielschenk commented 8 months ago

I'll gladly do! I will dive into the code as soon as I have time for it.

niccokunzmann commented 5 months ago

@danielschenk I had another thought about it.

What we can do with icalendar is ICS -> Python object -> ICS That does not require any validity and we want to support reading ICS files that are not valid as well as modifying them and saving them.

So, what I would propose is a method make_valid() on the calendar and components. That would i.e. write the mandatory fields like event UID or calendar scale and timezones used. That method can be improved time and time again. What do you think about that?

See also:

niccokunzmann commented 5 months ago

See also: https://github.com/collective/icalendar/discussions/662