Subject: [calsify] Updated JSCalendar draft calext-03

From: Robert Stepanek <[email-masked]>
Date: Wed, 09 May 2018 16:23:44 +0200

Hi, 

I have just submitted version 03[1] of the JSCalendar RFC draft. This
version mainly includes updates after implementing the latest spec
version in the Cyrus IMAP project.
Notable changes are:

 * *iCalendar Translation*: The section for mapping between JSCalendar
   iCalendar has been updated, including a new mapping table for the
   Location object.
 * *Alert mediaLinks and attachments*: these properties have been
   redefined from a list of linkIds to a map of Links. That is, alerts
   now maintain their own set of links, rather than pointing into the
   enclosing JSCalendar object link map.
 * *Object ids*: the values for the uid and productId properties must
   comply with the restrictions of their iCalendar equivalents. The
   allowed values for JSCalendar object-internal ids are restricted to
   valid JSON pointer format.
 * *localizations*: this property and its related requirements have been
   removed. The reasons for removal are:
   * It Is unclear if embedding multi-lingual translations in the object
     is the right solution, as opposed to using either external links or
     translation APIs.
   * The risk of getting the various translations out of sync on partial
     updates is significant.
   * Mapping localizations between JSCalendar and iCalendar is barely
     supported with standard properties, increasing the risk of getting
     out-of-sync data.
   * If required, localizations can be re-introduced as an extension,
     once the requirements are better understood.
 * *htmlDescription*: the mapping for HTML description to iCalendar has
   been defined to either use the ALTREP parameter (for legacy clients)
   or the upcoming STYLED-DESCRIPTION property (see eventpub-
   extensions[2]).
 * *Location*: the available Location feature values are now aligned
   with the definition of the CONFERENCE iCalendar property (RFC7986).
   The location description, URI and coordinates fields are now
   optional, name and rel have default values.
As always, we look forward to any feedback!

Cheers,
Robert

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-03
  2. https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions

---

From: Michael Douglass <[email-masked]>
Date: Wed, 9 May 2018 13:07:11 -0400

See below

On 5/9/18 10:23, Robert Stepanek wrote:
> Hi,
>
> I have just submitted version 03 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-03> of the 
> JSCalendar RFC draft. This version mainly includes updates after 
> implementing the latest spec version in the Cyrus IMAP project.
>
> Notable changes are:
>
>   * *iCalendar Translation*: The section for mapping between
>     JSCalendar iCalendar has been updated, including a new mapping
>     table for the Location object.
>     redefined from a list of linkIds to a map of Links. That is,
>     alerts now maintain their own set of links, rather than pointing
>     into the enclosing JSCalendar object link map.
>     allowed values for JSCalendar object-internal ids are restricted
>     to valid JSON pointer format.
>   * *localizations*: this property and its related requirements have
>     been removed. The reasons for removal are:
>       o It Is unclear if embedding multi-lingual translations in the
>         object is the right solution, as opposed to using either
>         external links or translation APIs.
>       o The risk of getting the various translations out of sync on
>         partial updates is significant.
>       o Mapping localizations between JSCalendar and iCalendar is
>         barely supported with standard properties, increasing the risk
>         of getting out-of-sync data.
>       o If required, localizations can be re-introduced as an
>         extension, once the requirements are better understood.
>
Multi-language support is very important - indeed a legal requirement in 
some places.
When publishing events there is no knowledge of the end recipient. It 
may pass through a number of aggregators and other intermediaries. 
Delivering one package with all required languages is absolutely the 
best way.
While there is indeed an issue with localizations being out of date that 
is something for workflow to deal with - pointing to external resources 
doesn't make that any easier. Sequence numbers can flag the need to check.
Translation APIs do a mediocre job - watch the Jimmy Fallon sketch on 
translating carols to another language and back again

After much discussion on how to achieve this in iCalendar it seemed a 
localization component was the best approach - while that may not happen 
in iCalendar I had hopes of seeing that appear in jscalendar. Either 
defining a localization component in iCalendar or simply dropping the 
localizations on translation (no worse than we are now) is better IMO 
than dropping the idea in jscalendar
>
>   * *htmlDescription*: the mapping for HTML description to iCalendar
>     has been defined to either use the ALTREP parameter (for legacy
>     clients) or the upcoming STYLED-DESCRIPTION property (see
>     eventpub-extensions
>     <https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions>).
>     with the definition of the CONFERENCE iCalendar property
>     (RFC7986). The location description, URI and coordinates fields
>     are now optional, name and rel have default values.
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Marten Gajda <[email-masked]>
Date: Wed, 9 May 2018 23:31:30 +0200

Hi Robert,

a few questions came to my mind while scanning the new version, see below.

*Section 3.2.3. Duration*

Is |PT3600S| a valid duration string? According to the ABNF it is. Maybe
add a paragraph about normalization.

*Section 4.3.1. Recurrence*

How does do clients have to treat start dates which are not in sync with
the recurrence rule? RFC 5545 says the recurrence set is “undefined”.
Can we be more specific in this spec?

*Section 4.3.2. Recurrence Overrides*

Are overrides allowed to predate the |start| property?

Is it valid to add a new instance (which doesn’t match an instance
created by a recurrence rule) and override the start at the same time
(to a different value)? Or to put it in other words, is it valid to add
an “RDATE” and override the start at the same time like this?

|"recurrenceOverrides": { "2018-05-09T23:00:00": { "start":
"2018-05-10T23:00:00" } } |

*Section 4.4.4. replyTo*

Method “web”: It’s 2018, can we ditch support for plain, insecure
“http”, and only support the secure version? A JSCalendar object with an
insecure replyTo address is invalid and MUST be rejected.

Cheers,

Marten

> As always, we look forward to any feedback!

​

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: Neil Jenkins <[email-masked]>
Date: Sun, 13 May 2018 21:50:25 -0400

On Thu, 10 May 2018, at 7:31 AM, Marten Gajda wrote:
> *Section
          3.2.3. Duration*

> Is PT3600S a valid duration string? According to the ABNF it is. Maybe add
        a paragraph about normalization.

Yes, this is valid. What do you suggest regarding normalization? Just a comment to say that the same durations may be represented by different strings, and this is something clients have to handle? Or define a normalization algorithm and specify clients MUST use the normalized form?

> How does do clients
        have to treat start dates which are not in sync with the
        recurrence rule? RFC 5545 says the recurrence set is
        “undefined”. Can we be more specific in this spec?

Given (pretty much) all clients handle this the same way these days, I agree this is worth specifying.

> Are overrides
        allowed to predate the start property?

I'd say yes. They can in iCalendar I believe, although client support may not be 100%.

> Is it valid to add a
        new instance (which doesn’t match an instance created by a
        recurrence rule) and override the start at the same time (to a
        different value)? 

I would again say yes, so that the validity of the recurrenceOverrides object can be easily checked syntactically, rather than having to do semantic checks against the recurrenceRule property of the parent object.

It's probably worth having an example in the spec that covers these two cases to make sure clients remember to handle them!

> *Section
          4.4.4. replyTo*

> Method “web”: It’s
        2018, can we ditch support for plain, insecure “http”, and only
        support the secure version? A JSCalendar object with an insecure
        replyTo address is invalid and MUST be rejected.

Seems reasonable to me, although in practice I wonder how many implementations will actually reject the whole object because of an http: *replyTo* property.

Neil.

---

From: Neil Jenkins <[email-masked]>
Date: Sun, 13 May 2018 21:56:49 -0400

Looking at this again, I realised today the EXDATE representation is problematic in that it is incompatible with the JMAP patch format. Specifically, by applying semantic meaning to mapping to `null`, you can't then use mapping to `null` in a patch as a means of removing that property, as that's a different action.

I suggest we instead represent EXDATE like so:
"recurrenceOverrides": {
    "2018-05-14T11:53:00": {
        "method": "cancel"
   }
}
This is both more obvious if you are looking at an object and have never seen the spec, and is consistent with the way this is represented in the iTIP messages sent out. I suggest the *method* property MUST NOT appear in an override if it's not a cancellation; if it is a cancellation it MUST be the only property in the object.

Neil.

---

From: Mike Douglass <[email-masked]>
Date: Mon, 14 May 2018 01:10:13 -0400

Sent from my iPhone

> On May 13, 2018, at 9:56 PM, Neil Jenkins <[email-masked]> wrote:
> 

I think we should introduce method: delete

There’s a difference between a deletion - which is what an exdate is - and a cancellation which should be an override with status cancelled. 

The second one should not be deleted - you need to tell the consumer that the event was canceled

---

From: Robert Stepanek <[email-masked]>
Date: Mon, 14 May 2018 14:40:33 +0200

On Mon, May 14, 2018, at 03:50, Neil Jenkins wrote:
>> How does do clients have to treat start dates which are not in sync
>> with the recurrence rule? RFC 5545 says the recurrence set is
>> “undefined”. Can we be more specific in this spec?> 
The relevant section in RFC 5545 defines: "The "DTSTART" property value
SHOULD be synchronized with the recurrence rule, if specified. The
recurrence set generated with a "DTSTART" property value not
synchronized with the recurrence rule is undefined."
Let's change SHOULD to MUST for JSCalendar. This causes a potential
difference in how  iCalendar and JSCalendar clients might display the
same event, but it's the same issue for two iCalendar clients, anyways.

>> Are overrides allowed to predate the start property?

> I'd say yes. They can in iCalendar I believe, although client support
Agreed.

>> (to a different value)?> 
> I would again say yes, so that the validity of the
> recurrenceOverrides object can be easily checked syntactically,
> rather than having to do semantic checks against the recurrenceRule
> property of the parent object.> 
> It's probably worth having an example in the spec that covers these
> two cases to make sure clients remember to handle them!
Agreed.

>> “http”, and only support the secure version? A JSCalendar object with
>> an insecure replyTo address is invalid and MUST be rejected.> 
> Seems reasonable to me, although in practice I wonder how many
> implementations will actually reject the whole object because of an
> http: *replyTo* property.
I'm OK with enforcing https but I wonder if there's a general guideline
at IETF for new RFCs around HTTPS or allowing fallback to HTTP? Did this
by chance already pop up during the security reviews of the JMAP spec?
Cheers,
Robert

---

From: Robert Stepanek <[email-masked]>
Date: Mon, 14 May 2018 14:48:40 +0200

> I think we should introduce method: delete

DELETE is problematic, as the current definition of the `method` property is required to match the allowed iTIP method values. If using DELETE, I wonder if that also would make sense for iTIP.

Alternatively, to express EXDATE and RDATE equivalents in JSCalendar, while keeping JMAP patch syntax in mind, we might just as well split the recurrenceOverrides property into

- recurrenceOverrides: for exceptions and RDATE
- recurrenceDeletions: for EXDATES. The value of this property is a map of recurrence-id to JSON true.

Cheers,
Robert

---

From: Robert Stepanek <[email-masked]>
Date: Mon, 14 May 2018 15:04:33 +0200

On Wed, May 9, 2018, at 19:07, Michael Douglass wrote:
> Multi-language support is very important - indeed a legal requirement
> in some places.
How are these places are dealing with this now in terms of calendaring?
>  best way.>  While there is indeed an issue with localizations being out of date
>  that is something for workflow to deal with - pointing to external
>  resources doesn't make that any easier. Sequence numbers can flag the
>  need to check.>  Translation APIs do a mediocre job - watch the Jimmy Fallon sketch on
>  translating carols to another language and back again> 
>  localization component was the best approach - while that may not
>  happen in iCalendar I had hopes of seeing that appear in jscalendar.
>  Either defining a localization component in iCalendar or simply
>  dropping the localizations on translation (no worse than we are now)
>  is better IMO than dropping the idea in jscalendar
There's clearly a value in localization support for some calendaring
users. OTOH it sounds as if the design issues were similar to what we
came to realize for JSCalendar, and there isn't one good answer?
This probably is a good occasion to put the claim of JSCalendar "to be
unambiguous, extendable and simple to process" to the test, and make
localizations an extension. Clients that choose to implement this
extension will benefit from localizations, we'll have more insight into
how defining a JSCalendar extension actually works out; and
implementations that don't bother can just ignore all of it.
Cheers,
Robert

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 14 May 2018 19:16:15 -0400

On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote:
> The relevant section in RFC 5545 defines: "The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified. The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined."
> 
> Let's change SHOULD to MUST for JSCalendar. This causes a potential difference in how  iCalendar and JSCalendar clients might display the same event, but it's the same issue for two iCalendar clients, anyways.

No, strongly disagree! The point Marten and I are making is that this *is* handled the same way by most (all?) existing clients, and so we should document that rather than leaving it undefined. Just changing the spec to say the rule MUST be synchronised with the start will only lead to interop issues.

> I'm OK with enforcing https but I wonder if there's a general guideline at IETF for new RFCs around HTTPS or allowing fallback to HTTP? Did this by chance already pop up during the security reviews of the JMAP spec?

JMAP has always said HTTPS only since the beginning I think.

Neil.

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 14 May 2018 19:25:52 -0400

> - recurrenceDeletions: for EXDATES. The value of this property is a map of recurrence-id to JSON true.

I don't like this idea. We deliberately chose to have a single property as it made it syntactically impossible to have an RDATE and and an EXDATE for the same time, reducing the chance of making mistakes and producing weird data. I think the { method: "cancel" } solution is much cleaner.

> There’s a difference between a deletion - which is what an exdate is - and a cancellation which should be an override with status cancelled.

Yes, but you can already override the status <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-03#section-5.1.5> property to "cancelled" to indicate an event is cancelled. If you create an EXDATE in an iCalendar system though, this will send out an iTIP message with method="cancel", so it seems reasonable to reuse that semantics here. I don't think we need to define a new method value.

Neil.

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 15 May 2018 11:50:49 +1000

On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote:
>> The relevant section in RFC 5545 defines: "The "DTSTART" property
>> value SHOULD be synchronized with the recurrence rule, if specified.
>> The recurrence set generated with a "DTSTART" property value not
>> synchronized with the recurrence rule is undefined.">> 
>> same event, but it's the same issue for two iCalendar clients,
>> anyways.> 
> No, strongly disagree! The point Marten and I are making is that this
> *is* handled the same way by most (all?) existing clients, and so we
> should document that rather than leaving it undefined. Just changing
> the spec to say the rule MUST be synchronised with the start will only
> lead to interop issues.
We discussed this in the Cyrus dev team meeting last night.  In the same
way that JMAP is leading to attempts in EXTRA to backfill some of the
best improvements in to the existing IMAP protocol, it makes sense to do
an iCalendar bis (iCalendar 2.1!) which does nothing but nail down
undefined behaviour such that new implementations have a guideline.
I think the SHOULD to MUST came out of a comment by Ken, and I missed
that. I agree with Neil here that the right thing is to document
existing behaviour and mandate the most popular existing approach.
>> I'm OK with enforcing https but I wonder if there's a general
>> guideline at IETF for new RFCs around HTTPS or allowing fallback to
>> HTTP? Did this by chance already pop up during the security reviews
>> of the JMAP spec?> 

I still think it's a layering violation to specify the specifics of the
transport layer in the payload spec.
However, there seems a very strong IETF insistence towards mandating
HTTPS everywhere, so explicitly doing so increases the chance of
passing review.
Bron.

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

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 May 2018 23:01:56 -0400

On 05/14/2018 09:50 PM, Bron Gondwana wrote:
>>> value SHOULD be synchronized with the recurrence rule, if 
>>> specified. The recurrence set generated with a "DTSTART" property 
>>> value not synchronized with the recurrence rule is undefined."
>>>
>> /is/ handled the same way by most (all?) existing clients, and so we 
>> the spec to say the rule MUST be synchronised with the start will 
>> only lead to interop issues.
>
> We discussed this in the Cyrus dev team meeting last night.  In the 
> same way that JMAP is leading to attempts in EXTRA to backfill some of 
> the best improvements in to the existing IMAP protocol, it makes sense 
> to do an iCalendar bis (iCalendar 2.1!) which does nothing but nail 
> down undefined behaviour such that new implementations have a guideline.
>

And what is existing behavior?  If most implementations ignored a 
SHOULD, then apparently SHOULD doesn't carry much weight.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Robert Stepanek <[email-masked]>
Date: Tue, 15 May 2018 09:11:14 +0200

On Tue, May 15, 2018, at 05:01, Ken Murchison wrote:
>>>> value not synchronized with the recurrence rule is undefined.">>>> 
>>>> difference in how iCalendar and JSCalendar clients might display
>>>> the same event, but it's the same issue for two iCalendar clients,
>>>> anyways.>>> 
>>> No, strongly disagree! The point Marten and I are making is that
>>> this *is* handled the same way by most (all?) existing clients[..]>> 
>> [...] I agree with Neil here that the right thing is to document
>> existing behaviour and mandate the most popular existing approach.> 
It also was my understanding, that the SHOULD approach is the one chosen
by most current implementations? If it's the other way round, I agree it
doesn't make sense to enforce a rule that's ignored in practice.

---

From: Garry Shutler <[email-masked]>
Date: Tue, 15 May 2018 09:16:09 +0100

> The "DTSTART" property value SHOULD be synchronized with the recurrence
rule, if specified.

I think this is fine and correct for what you are currently allowed to do.
Generally recurrence rules do align with the DTSTART (which sits ok with
SHOULD) but they do not have to, and in practice do not always, which means
it can't be changed to a MUST.

> The recurrence set generated with a "DTSTART" property value not
synchronized with the recurrence rule is undefined.

In practice, this has become defined by how everyone has ended up
implementing it. Broadly speaking it is something like: "DTSTART MUST be
considered a member of any recurrence rule, whether it aligns with it or
not". That's likely too inaccurate a statement but I thought a stab at it
would help.

*Garry Shutler* | CTO

On 15 May 2018 at 08:11, Robert Stepanek <[email-masked]> wrote:

> recurrence set generated with a "DTSTART" property value not synchronized
> with the recurrence rule is undefined."
>
> difference in how iCalendar and JSCalendar clients might display the same
> event, but it's the same issue for two iCalendar clients, anyways.
>
>
> No, strongly disagree! The point Marten and I are making is that this *is*
> handled the same way by most (all?) existing clients[..]
>
>
> [...] I agree with Neil here that the right thing is to document existing
> behaviour and mandate the most popular existing approach.
>
>
> And what is existing behavior?  If most implementations ignored a SHOULD,
> then apparently SHOULD doesn't carry much weight.
>
>

---

From: Marten Gajda <[email-masked]>
Date: Tue, 15 May 2018 23:11:57 +0200

How about using |false| to identify exdates?

|"recurrenceOverrides": { "2018-05-14T11:53:00": false } |

I don’t really like varying types for object members but in this case it
seems to be a reasonable solution which doesn’t bear any ambiguity.

Marten

Am 14.05.2018 um 03:56 schrieb Neil Jenkins:

> Looking at this again, I realised today the EXDATE representation is
> problematic in that it is incompatible with the JMAP patch format.
> Specifically, by applying semantic meaning to mapping to `null`, you
> can't then use mapping to `null` in a patch as a means of removing
> that property, as that's a different action.
>
> |"recurrenceOverrides": { "2018-05-14T11:53:00": { "method": "cancel" } }|
> This is both more obvious if you are looking at an object and have
> never seen the spec, and is consistent with the way this is
> represented in the iTIP messages sent out. I suggest the
> /method/ property MUST NOT appear in an override if it's not a
> cancellation; if it is a cancellation it MUST be the only property in
> the object.
>
> Neil.
>
>

​

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 15 May 2018 22:45:51 -0400

Testing this further, I may have to take back my claim as I have seen some inconsistencies in various services (although they seem to be more poor support of complex rules in general rather than an issue of alignment with start date). Regardless, I think rather than refer to the poor explanation of recurrence rules in RFC5545, we should directly define the semantics in this spec and do so in a way that does not require alignment with the start date since this is often found in the wild.

Here is my attempt at that definition. I believe this matches the semantics of RFC5545 as currently implemented in at least Apple's and FastMail's calendar clients.

------
A recurrence rule specifies a set of set of date-times for recurring calendar objects. A recurrence rule has the following semantics:

 1. A set of candidates is generated. This is every second within a period defined by the *frequency* property:
   * yearly: every second from midnight on the 1st January (inclusive) to 
midnight the following 1st January (exclusive)
   * monthly: every second from midnight on the 1st of a month (inclusive) to
midnight on the 1st of the following month (exclusive)
   * weekly: every second from midnight (inclusive) on the first day of the week 
(as defined by the *firstDayOfWeek* property, or Monday if omitted), to  midnight 7 days later (exclusive).
   * daily: every second from midnight at the start of the day (inclusive) to
midnight at the end of the day (exclusive).
   * hourly: every second from the beginning of the hour (inclusive) to the
beginning of the next hour (exclusive).
   * minutely: every second from the beginning of the minute (inclusive) to the
beginning of the next minute (exclusive).
   * secondly: the second itself, only.
 2. Each date-time candidate is compared against all of the *byX* properties of 
the rule except *bySetPosition*. If any property in the rule does not match the date-time, it is eliminated. Each *byX* property is an array; the date-time matches the property if it matches any of the values in the array. The properties have the following semantics:

   * byMonth: the date-time is in the given month.
   * byMonthDay: the date-time is on the given day of the month. Negative 
numbers mean the nth last day of the month.
   * byDay: the date-time is on the given day of the week. If the day is 
prefixed by a number, it is the nth occurrence of that day of the week within the month (if frequency is monthly) or year (if frequency is yearly). Negative numbers means nth last occurrence within that period.
   * byYearDay: the date-time is on the nth day of year. Negative numbers mean
the nth last day of the year.
   * byWeekNo: the date-time is in the nth week of the year. Negative numbers 
mean the nth last week of the year. This corresponds to weeks according to 
week numbering as defined in ISO.8601.2004, with a week defined as a seven 
day period, starting on the *firstDayOfWeek* or Monday if omitted.
Week number one of the calendar year is the first week that contains at 
least four days in that calendar year.
   * byHour: the date-time has the given hour value.
   * byMinute: the date-time has the given minute value.
   * bySecond: the date-time has the given second value.
 3. If a *bySetPosition* property is included, this is now applied to the 
ordered list of remaining dates (this property specifies the indexes of date-times to keep; all others should be eliminated. Negative numbers are indexes from the end of the list, with -1 being the list item).

 4. Any date-times *before* the start date of the event are eliminated (see 
below for why this might be needed).

 5. If further dates are required (we have not reached the *until* date, or *count* limit) skip the next (interval - 1) sets of candidates, then continue from 
step 1.

When determining the set of occurrence dates for an event, the following extra rules must be applied:

 1. The *start* date-time is always the first occurrence in the expansion (and 
is counted if the recurrence is limited by a "count" property), even if it 
would normally not match the rule.

 2. The first set of candidates to consider is that which would *contain* the 
start. This means the first set may include candidates before the start; 
such candidates are eliminated from the results in step (4).

 3. The following properties MUST be implicitly added to the rule under the 
given conditions:

If frequency > "secondly" and no bySecond property:

   * Add a *bySecond* property with the sole value being the seconds value of 
the start date-time.
If frequency > "minutely" and no byMinute property:

   * Add a *byMinute* property with the sole value being the minutes value of 
the start date-time.
If frequency > "hourly" and no byHour property:

   * Add a *byHour* property with the sole value being the hours value of 
the start date-time.
If frequency is "weekly" and no byDay property:

   * Add a *byDay* property with the sole value being the day-of-the-week of
the start date-time.
If frequency is "monthly" and no byDay property and no byMonthDay property:

   * Add a *byMonthDay* property with the sole value being the day-of-the-month
of the start date-time.
If frequency is "yearly" and no byDay, byYearDay or byWeekNo properties:

 * if there is no byMonthDate property: 
   * Add a *byMonthDay* property with the sole value being the day-of-the-month
of the start date-time.
 * if there is no byMonth property: 
   * Add a *byMonth* property with the sole value being the month of the start
date-time.

------

Neil.

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 15 May 2018 23:26:56 -0400

On Wed, 16 May 2018, at 7:12 AM, Marten Gajda wrote:
> How about using false to identify exdates?

I don't mind this, but  I wonder if it's likely to be a real headache if implementing in strongly typed languages? Also, is mapping to `true` forbidden or the same as mapping to `{}` (i.e. it's an RDATE with no further changes)?

The… impurity of it annoys me a bit. But I have to say it's a reasonably pragmatic solution, and I'm happy to go with it if there's no strong objections.

Neil.

---

From: Robert Stepanek <[email-masked]>
Date: Wed, 16 May 2018 09:57:02 +0200

On Wed, May 16, 2018, at 05:26, Neil Jenkins wrote:
> I don't mind this, but  I wonder if it's likely to be a real headache
> if implementing in strongly typed languages?
I share this concern.

In addition, during the last JMAP session at IETF we had people asking
for OpenAPI3 or JSON schema definitions. In my understanding, a variant-
type property would require to use less common features of these
definition languages, and hence make the resulting schema for JSCalendar
more complicated and code generation brittle.
I don't think that the shortcomings of particular technologies or tools
should guide our design. But JSCalendar claims to be "simple to
process", and the benefits of using `false` in this particular case
don't seem to me to warrant its potential risks.
Of all the proposals, I vouch for `method:cancel`, as it neither extends
iTIP vocabulary, nor requires special handling of the payloads.
Implementations can apply the same patch mechanism to all entries in
recurrenceOverrides and if the resulting patched object instance has a
`method:cancel` can just ignore it.

---

From: Marten Gajda <[email-masked]>
Date: Wed, 16 May 2018 12:55:55 +0200

I'm not keen on this either. I'm usually working with a strongly-typed
language and variant-type members can be a real pain.

Anyway, `method:cancel` has completely different semantics and many
clients still show canceled instances, just with the title crossed out.
That's not a good option either.

So here is another option:

* add a new dedicated property to identify exdates, like so?
```
"recurrenceOverrides": {
   "2018-05-16T12:50:00": { "excluded": true }
}
```

I like "excluded" because it doesn't imply the instance ever existed
(which "method:deleted" does, sort of). Not that it matters much though.

Marten

Am 16.05.2018 um 09:57 schrieb Robert Stepanek:
> for OpenAPI3 or JSON schema definitions. In my understanding, a
> variant-type property would require to use less common features of
> these definition languages, and hence make the resulting schema for
> JSCalendar more complicated and code generation brittle.
>
> I don't think that the shortcomings of particular technologies or
> tools should guide our design. But JSCalendar claims to be "simple to
> Of all the proposals, I vouch for `method:cancel`, as it neither
> extends iTIP vocabulary, nor requires special handling of the
> payloads. Implementations can apply the same patch mechanism to all
> entries in recurrenceOverrides and if the resulting patched object
> instance has a `method:cancel` can just ignore it.
>
>

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: Neil Jenkins <[email-masked]>
Date: Thu, 17 May 2018 06:52:51 -0400

>     "2018-05-16T12:50:00": { "excluded": true }
 
I could certainly go with this. I think we've agreed:
 * We want to keep it all part of recurrenceOverrides.
 * We don't want to map to a different JSON type.
 * Therefore we need to map to an object with a single key/value property that signifies this date should be omitted from the recurrence set.
Whether that property is `method: 'cancel'` or `excluded: true` doesn't bother me too much. I can see how using a new property avoids potential confusion that this is about scheduling in some way, so this seems reasonable.

Neil.

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 18 May 2018 10:00:12 +1000

On Thu, May 17, 2018, at 20:52, Neil Jenkins wrote:
> Whether that property is `method: 'cancel'` or `excluded: true`
> doesn't bother me too much. I can see how using a new property avoids
> potential confusion that this is about scheduling in some way, so this
> seems reasonable.
I agree.  My proposal of "method:cancel" was being too smart.
"excluded:true" is both more obvious to the casual observer, and less
overloading of meaning.  The thing which frustrates me the most when
implementing is when the same term is used for two different and
slightly incompatible meanings (like IMAP's "UNSEEN" in status vs
"UNSEEN" in select response).
In summary - I support excluded: true

Bron.