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

From: Doug Royer <[email-masked]>
Date: Sat, 11 May 2019 11:53:42 -0600

On another thread (in [email-masked]) someone declared 
draft-ietf-calext-jscalendar as a replacement for iCalendar [RFC5545]. 
Not sure if that was the official position or an individuals view. I 
initially read the draft and updates with the idea that it was another 
representation of iCalendar.

First, a ton of hard work was done on this draft. My comments below are 
my second thoughts after hearing it is a replacement and not a 
representation of iCalendar. So I re-read this draft with replacement in 
mind. These are not necessarily problems, just thoughts and questions.

  **I understand that many of these topics may have been discussed on 
the mailing list. However, if not in the spec when released, they will 
be confusing. **

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?

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 ).

2.1 Same with updates to events that have recurrences. EXACTLY what is 
sent in the update? A complete replacement? Just what changes? These are 
also ambiguous in iCalendar/iTIP/iMIP.

3. iTIP/iMIP Is a jCal iTIP/iMIP replacement in the works? If not, those 
rescheduling ambiguities still exist. What (exactly) to send back when 
requesting a change to the schedule. Send the entire object, just the 
recurrence-id that is being requested with the proposed updates? Or what?

3.1 Are jCal iTIP/iMIP messages sent in jCal format or iCalendar format?
What is the jCal mapping for the iTIP/iMIP objects? How are PUBLISH, 
REQUEST, REPLY, ADD, ... method represented in jCal? As this spec does 
not mention them, does a CUA send them out in iCalendar format, even 
when the original message was in jCal format? Is there a plan? Or are 
the iTIP methods to be declared obsolete?

4. How does this relate to WebDAV and its objects, methods, or 
procedures? Only a brief mention is included.

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

6. Unrelated to ambiguous. Why are alarms/alerts still sent? Does anyone 
accept an alarm the organizer sends out? Example, I live 30 minutes 
away. What good is a 5-minute alarm to me? What do you do if someone 
sends an updated alarm/alert in an iTIP COUNTER? Is it ignored? Used as 
the suggested update?

6.1 Will people really be sharing the 'snoozed' property of an 
alarm/alert with others?

6.2 Alarm/alert "...  *acknowledged*: "UTCDate" (optional)

       When the user has permanently dismissed the alert the client MUST
       set this to the current time in UTC.  Other clients which sync
       this property can then automatically dismiss or suppress duplicate
       alerts (alerts with the same alert id that triggered on or before
       this date-time).

Is there a plan to separate user specific data from shared data? Clearly 
this is not to be shared with the organizer or other participants. And 
is not supposed to be updated on the master object from the organizer. 
(Thinking WebDAV where everyone can share the same link to the same event).

Their seems to be two kinds of data, API data (alerts) and public data 
(what the organizer would send). What implementations send back and 
forth between participant and organizer is not defined (ambiguous).

This is kind of talked about under "4.6.1 localizations", but I 
understand 'localizations' to mean language specific, not private data.
See useDefaultAlerts under localizations.

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

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/...

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.

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

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

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

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?

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

14. In 4.4.3 privacy: what is a 'sharee'? Is a sharee a participant? Or 
a non-Participant? How can a completely hidden ("as though it did not 
exist") calendar be shared?

14.1 Is any calendar event shared when it has more than 1 participant? 
(ambiguous) Or does shared mean the same object is shared between 
participants (as in one persistent storage object shared between 
participants)? Because if the objects have multiple copies (one per 
calendar user agent), then what does secret mean? Does it mean that 
calendar user agents MUST NOT make the event viewable by others in their 
own calendars? So they would just mark it as unavailable time (ambiguous).

14.2 Public, so can I limit what I share and still call it public. Can I 
for example limit the viewing of other participants, but otherwise make 
it public?

14.3 "private" and "hidden ... [from]... sharee". From participants? Or 
just from  non-participants?

14.4 Are not ALL calendar objects shared when there is more than one 
participant?

14.5 The same iTIP problem exists. When a participant updates their 
attendee status, and the calendar is public, what exactly does (if 
anything) the organizer send out to other participants? I would prefer 
nothing at all.

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

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 13 May 2019 10:56:24 -0400

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 
> [...] So I re-read this draft with replacement in 

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.

> should have never made it into iCalendar). Is this by design? If so, 

 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

> 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.

> sent in the update? [...]
> 3. iTIP/iMIP Is a jCal iTIP/iMIP replacement in the works? [...]
> 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.

> 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 

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.

> what NOT to send: Alarms, Alert updates/snooze/...

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

> 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.

> 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.

> 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.

> ignore this property from organizer.

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

> be valid to set it to false? What is the point of ever being able to 

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.

> [..]

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!

> 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)

---

From: Doug Royer <[email-masked]>
Date: Mon, 13 May 2019 15:12:55 -0600

On 5/13/19 8:56 AM, Robert Stepanek [Masked] wrote:
> Preview: Doug, many thanks for your feedback - much appreciated. Pleas

> 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.

I mean as described in the [email-masked] list email as described in my 
original post to this list.

> As to replacement: ...

Thanks for the replies ... new drafts to read ... :-)

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 13 May 2019 16:08:49 -0600

Why change the names and some formats of existing types?
One example why were the dashes added to date? (YYYYMMDD vs YYYY-MM-DD)

It seems like a lot of work is being done to make it incompatible and 
complicate the conversion process.

In some cases only the case of the token was changed (UID -> uid).
I do not see a technical reason, and it just adds to some confusion.
Does it really matter to any code? Users will not see the contents.

It just seems that someone did not like the names and wanted to start over.

--

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 14 May 2019 10:42:04 +1000

> One example why were the dashes added to date? (YYYYMMDD vs YYYY-MM-DD)

Because rather than define its own date-time format like iCalendar, JSCalendar uses RFC3339 <https://tools.ietf.org/html/rfc3339>, making it easier to use with a lot of existing libraries.

> In some cases only the case of the token was changed (UID -> uid).

Clear understandable names and consistent capitalisation inline with common JSON object structure practices were preferred over keeping the exact same names for properties as iCalendar.

Regards,
Neil.

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 14 May 2019 10:50:08 +1000

Hi Doug,

Thanks for engaging here - I'm glad you came across and took a look. This sort of thorough review is really important to creating a good document. I'm going to try to address the reasoning behind one specific bit here -- why differences!

Cheers,

Bron.

> One example why were the dashes added to date? (YYYYMMDD vs YYYY-MM-DD)

rfc3339 `full-date` and improved readability. YYYY-MM-DD is far superior in terms of lack of ambiguity and even lack of being accidentally interpreted as an integer when roundtripped through type-unsafe languages.

> complicate the conversion process.

Compatibility is important - a lack of ambiguity and attractiveness to developers is more important if it wants to gain adoption than slavish compatibility with the existing format.

> Does it really matter to any code? Users will not see the contents.

ICALENDAR is case insignificant. JSON is case significant. It's necessary to chose an explicit case for JSON, and we decided on lowercase because that's what's generally expected by JSON-native developers.

> It just seems that someone did not like the names and wanted to start over.

Usability and familiarity to programmers are important factors, and they were considered when creating a JSON format which is expected to attract usage.

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]