[calsify] Change of status and authors for jscalendar-icalendar

[Robert Stepanek <[e-mail]>]

We are going to change our approach for the jscalendar-icalendar internet draft:

The expired I-D had aimed to become a Standard document. Restarting work on this, it looks more appropriate to go for Experimental status. This better reflects the fact that whatever conversion rules we'll come up with, they will first have to prove in practice.

I will be the sole author of this document. Mike already is working on a couple of other documents for the working group. Joris volunteered to stay as author but is busy with other work in the jmap working group, too. Since jscalendar-icalendar is my main focus for 2024, I'd rather produce the document on my own. I'm grateful to both Mike and Joris offering to keep on giving input to the document.

My goal for jscalendar-icalendar is to define conversion rules for all currently IANA-registered elements of iCalendar and JSCalendar. It must be possible to convert between iCalendar and JSCalendar without data loss.

A conversion rule is either:
 1. "Convert this element to that standard element in the other format". This is for elements that are first-class features in both formats, e.g DURATION and "duration".
 2. "Convert this element to that conversion-specific property". This is for elements that only are available in one format but not the other. This might be the PERIOD type, the "localizations" property or DTEND. A "conversion-specific" property might be something similar to "vCardProps <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-vcard-15.html#name-property-vcardprops>" in the jscontact-vcard document.
Only as an exception a new general-use IANA element might get registered as part of jscalendar-icalendar for either JSCalendar or iCalendar. If any, these are supposed to be trivial additions which are undisputed in the calext working group.

Likewise, the jscalendar-icalendar document must not introduce breaking changes to the current format definitions. This is left to some later jscalendarbis or icalendar3.0 documents, which might be informed by gaps or deficiencies that were identified in jscalendar-icalendar.

Regards,
Robert