Re: [calsify] draft-ietf-calext-jscalendar - thoughts

["Robert Stepanek" <[e-mail]>]

Doug, many thanks for your feedback - much appreciated. Please see my answers below:

On Sat, May 11, 2019, at 7:53 PM, Doug Royer wrote:
> I initially read the draft and updates with the idea that it was another 
> representation of iCalendar.
> [...] So I re-read this draft with replacement in 
> mind. These are not necessarily problems, just thoughts and questions.

I am not sure what you mean by "replacement" and "representation", so let me clarify my point of view:

JSCalendar defines a data model and format for calendaring data, as an alternative to iCalendar. It shares a lot of concepts with iCalendar, but it deliberately isn't 100% compatible. If by "representation" you mean "a different format to express exactly the same thing", then JSCalendar isn't a representation of iCalendar.

As to replacement: we think that JSCalendar is the better alternative to iCalendar for a large number of use case (otherwise, why we bother with it). But as it currently stands, it just defines a data format. We haven't started on working out how to use it with iMIP/iTIP, and we are just getting started defining how to use JSCalendar with other protocols (e.g. JMAP). The current RFC document is the ground work required to get started with this. It can be useful in its own as a data format, but as a replacement in iMIP/iTIP it is not ready.

> 1. If it is a replacement for iCalendar, please provide a list of 
> obsoleted properties and and some kind of migration path for the 
> replacement. Some comments in the spec imply obsoleted properties, they 
> are not named at all in this spec. (DTEND for example - which I think 
> should have never made it into iCalendar). Is this by design? If so, 
> what exactly?

 We recently uploaded an informational RFC draft which describes how JSCalendar and iCalendar could be mapped, but implementations are free to choose their own conversions:

https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar-00

> 2. Ambiguous ways of representing the same event. When it comes to 
> recurring events, they can still be represented with an RRULE 
> (recurrenceRule) OR with RDATE (recurrenceDates), or a combination. I 
> could not find mention of a preferred way. (Something like use 
> recurrenceRule only, except when it is not possible, then add 
> recurrenceDates, and/or recurrenceOverrides ).

We had discussed this, but decided against it. One of the reasons is, that it makes checking the validity of a JSCalendar object more complex, as implementations need to apply recurrence expansion during validity checking.

> 2.1 Same with updates to events that have recurrences. EXACTLY what is 
> sent in the update? [...]
> 3. iTIP/iMIP Is a jCal iTIP/iMIP replacement in the works? [...]
> 3.1 Are jCal iTIP/iMIP messages sent in jCal format or iCalendar format?
> 4. How does this relate to WebDAV and its objects [...]

All this is out of scope of the data format. We don't have a proposal, yet (but we'd be happy to hear any!).

> 5. Is a iCalendar to jCal migration path specification in the works?

I guess you mean JSCalendar, rather than jCal? Please see my reply to your question 1.

> 6. Unrelated to ambiguous. Why are alarms/alerts still sent? Does anyone 
> accept an alarm the organizer sends out?

Similar to iMIP, we don't enforce this on the data format level. Personally, I agree that alerts only make sense per user and organizers typically don't know which alerts I require.

> 6.3 Where is valarm? Gone? Alert mentions alarms, yet no definition of 
> alarm.

JSCalendar standard alerts are the alternative to VALARM. They define time-based triggers and have a "display" and "email" action, but without describing the content of these triggers. That's due to the observation, that server providers and client devices typically have their own way to render the alert, and especially devices can make better decisions how to alert a user under the current circumstances.

> 7. Under "Security Considerations"
> Should it mention "do not send private data to organizer"? And a list of 
> what NOT to send: Alarms, Alert updates/snooze/...

Again, that will to be defined, but is out of scope of the current RFC.

> 8. I am confused by highlighting meaning of *this*, _this_, and "this" 
> As described in 1.3 and the highlighting methods throughout this spec.
> I have not seen these used in a draft before.

The notation should make things simpler to read, not make them more confusing. I'm sorry if it failed on you. Would you have an example of an RFC which achieves this better? I'll also look at recent RFCs for different formats.

> 9. The term "master object" is used once and not defined. Is this the 
> organizer object? Or the users copy?

It meant the main event in a recurring event (e.g. in iCalendar the VEVENT without RECURRENCE-ID). I took note to phrase this better.

> 10. The 'JSGroup' object seems to be new to jCalendar and iCalendar. Did 
> I miss something in past documents?

 JSGroup is a very light wrapper around JSEvent and JSTask. It's similar to a VCALENDAR component that contains VEVENT and VTODO.

> 11. Color (4.2.10). Can't imagine implements would not just totally 
> ignore this property from organizer.

Out of scope of the data format, but yes: agreed :)

> 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever be 
> set to false? Can I send it in object set to false at all? When would it 
> be valid to set it to false? What is the point of ever being able to 
> send one set to false?

This property represents what's EXDATEs in iCalendar. It could be set to false, but it's only really useful to set it to true, or not at all.

> 13. Should alerts be excluded from a 'PatchObject'?

I guess you mean during an iMIP exchange, right? That would sense, but it's not decided in this RFC.

> 14. In 4.4.3 privacy: what is a 'sharee'? Is a sharee a participant? Or 
> [..]

I'm sorry to sound like a broken record, but we don't address this in this RFC. But these are all good questions that we'll need to answer!

> 15. 4.4.5 participants "memberOf" Exactly how is this used? It is a new 
> property to calendar - correct?

It's iCalendar alternative is the MEMBER parameter on the ATTENDEE (https://tools.ietf.org/html/rfc5545#section-3.2.11)