Consider adding fields from RFC-7986

[stefanv]

RFC-7986 allows for calendar proprties such as a name.

Would adding this be in scope for the project? I'm happy to make a PR.

[N-Coder]

Ah, RFC 7986 added a list of new properties. Sure, a PR for this would be nice!

Handling this specific property might be a little more difficult than just adding a name : str attr.ib field to iCalendar, because the field might have multiple values:

This property can be specified multiple times in an iCalendar object. However, each property MUST represent the name of the calendar in a different language.

I guess the best way to support this would be using the name : str field only if there is a single name and throwing the respective ContentLines into the extra field otherwise. Unfortunately, there is no Converter support for that yet, so a PR would also need to create that - if this is the way we want to represent this. I guess the only downside would be that you then have two different places where a name could end up / be specified, which also might conflict with each other. But still, a naïve implementation might be okay with only looking at the singular field, while a more involved one would need a more complex logic anyways.

[C4ptainCrunch]

Another thing we should keep in mind is that before RFC7986 there was an extension for RFC5545 that introduced X-WR-CALNAME that has the same meaning. Should we parse both and put them in the same API field ? How to we serialize it afterwards ?

[N-Coder]

I guess as long as there is no conflicting information we can throw everything into the name field. Always serializing that field according to RFC7986 and thus "modernizing" any files that make the parse + serialize cycle also sounds okay to me. If you want to serialize compliant to RFC5545 you can always put a X-WR-CALNAME into the extras.

The only information that gets lost this way is whether an input file that has a single (i.e. non-conflicting/internationalized) name specification was using the RFC7986 or the RFC5545 format (i.e. to which standard the file complied). We could store this meta information in the extra_params, but I don't really see the need for that, just as I don't see the need for being able to globally switch the serialization format between RFC7986, RFC5545 and same-as-input instead of always sticking to the most recent.