[calsify] Re: Final comments on jscalendar-icalendar and jscalendarbis

[Robert Stepanek <[e-mail]>]

Hi Mauro and all,

I just published new versions for the jscalendarbis <https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendarbis/>, jscalendar-icalendar <https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar/> and icalendar-jscalendar-extensions <https://datatracker.ietf.org/doc/draft-ietf-calext-icalendar-jscalendar-extensions/> I-Ds. They incorporate the feedback that I address in this email and the new "owner" rule definitions.

Specifically for the "owner" rule, the jscalendar-icalendar I-D contains updated conversion rules and examples for the Participant object and ORGANIZER property. The goal is to meaningfully represent scheduled events where the owner only is represented by the ORGANIZER, or the owner is represented as both an ORGANIZER and ATTENDEE, or where multiple ATTENDEEs have the new OWNER role set. I'd appreciate any feedback on these updated rules. 

On Tue, Oct 7, 2025, at 7:45 PM, Mauro De Gennaro wrote:
> After reading JMAP for Calendar I now see why PRODID needs to be at the event level. How about making PRODID optional and do not add it to Event/Task if the object is contained in a JSCalendar Group which defines a PRODID?

Agreed, I rephrased the conversion rule for PRODID accordingly.

>> 
>>> *- 2.3.33. RDATE:*
>>> - I've seen a few iCals containing RDATEs using periods, for example: "RDATE;VALUE=PERIOD;TZID=Europe/Berlin:20240913T120000/PT2H". Perhaps an example could be added showing how to map this to the "duration" property in the recurrence override. But maybe this is an edge case.
>> 
>> Are you converting this currently? Do you suggest something like the following snippet? Our implementation currently does not support PERIOD RDATEs for JSCalendar.
> 
> I’m also not converting RDATEs currently, but since in my test suite I have a few iCal containing these, I was wondering how common they are and if it makes sense to convert them to JSCalendar.

I haven't seen them being used at all.

>>> *- 5.1.1. iCalComponent*
>>> - Clarify that iCalComponents should only be defined in JSCalendar objects that can (or could be) converted to iCalendar components (Event, Task, Alarm, Location) but not in other objects such as Link or VirtualLocation.
>> 
>> Isn't this clear from the first sentence "This contains information about an iCalendar component that got converted to JSCalendar."?
> 
> Yes, but I was thinking the scenario where a user manually adds an iCalComponent to a JSCalendar object so it is converted to a certain unsupported iCalendar property. But most likely this won’t ever happen.

I think it's up to the implementation how to deal with this. In our implementation, we only consider "iCalComponent" at places where we are prepared to deal with it. An implementation is free to ignore all of the "iCalComponent" property.

> - If we do the above, perhaps we can remove the "name" property from iCalComponent? I believe the correct component name is implicit as defining other/unexpected component types will result in an invalid iCal.
>> 
>> I don't think we should remove the "name" property, but we might make it optional for most cases. We would define a default. value for each JSCalendar object that converts to an iCalendar component (e.g. we could define the default name for a Location object to be VLOCATION).
> 
> Making it optional sounds good.

I kept it mandatory for now. I took a couple of attempts to redefine it to be optional but all definitions turned out to be awkward, because the "name" being optional or mandatory depends on the context of where the property is set. I understand that this somewhat bloats the iCalendar conversion-specific properties, but these properties only should be used sparingly anyway. I'm open to make it optional if we can come up with a simple definition.

> *- Parameters:*
>>> - DERIVED: Should the specification recommend what to do with DERIVED properties? Should they be placed in iCalComponent or removed?
>> 
>> Right now, it just states they do not convert to JSCalendar. My implementation does not put them in the iCalComponent. Do you suggest something differently?
> 
> My implementation removes it in most cases but in others (for example, when found in an FN property), it adds it to iCalComponent.

Nit: the FN property is a vCard property, not an iCalendar property. In any case, I still think it should not convert. But like any other conversion-specific property, it's only indicative anyway.

> My implementation adds TZID to iCalComponent only if it is not a IANA TZ. For example:
> 
> BEGIN:VCALENDAR
> BEGIN:VEVENT
> SUMMARY:Test
> DTSTART;TZID=W. Europe Standard Time:20201124T110000
> DTEND;TZID=W. Europe Standard Time:20201124T113000
> DTSTAMP:20201119T112915Z
> TRANSP:OPAQUE
> STATUS:CONFIRMED
> END:VCALENDAR
> 
> Converts to:
>     {
>       "@type": "Event",
>       "freeBusyStatus": "busy",
>       "start": "2020-11-24T11:00:00",
>       "title": "Test",
>       "duration": "PT30M",
>       "updated": "2020-11-19T11:29:15Z",
>       "iCalComponent": {
>         "convertedProperties": {
>           "start": {
>             "parameters": {
>               "TZID": "W. Europe Standard Time"
>             }
>           },
>           "duration": {
>             "parameters": {
>               "TZID": "W. Europe Standard Time"
>             },
>             "name": "DTEND"
>           }
>         },
>         "name": "vevent"
>       },
>       "priority": 5,
>       "timeZone": "Europe/Berlin"
>     }

I updated section "Timezone identifiers (2.1.4)" in the jscalendar-icalendar I-D to mention this as an option and also added an according example for converting the DTSTART property with a custom time zone.

BTW: Your example suggests that your jCal implementation is slightly wrong. RFC 7265 section 3.5 states that the name of the parameters MUST be in lowercase. Accordingly, jscalendar-icalendar defines that the "name" properties in the ICalComponent and ICalProperty objects MUST be lowercase, too.

Regards,
Robert