Subject: [calsify] WGLC JSCalendar

From: Daniel Migault <[email-masked]>
Date: Tue, 15 Oct 2019 18:03:15 +0000

Hi,

This email starts a WGLC for draft-ietf-calext-jscalendar [1].

The WGLC will end on October 30. Please review the document and provide your feed back on the mailing list. All feed back are useful for our AD to move the work forward.

Yours,
Daniel

[1] https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20

From: calsify <[email-masked]> On Behalf Of Neil Jenkins
Sent: Tuesday, October 15, 2019 11:56 AM
To: [email-masked]
Subject: [calsify] Request to start last call for JSCalendar

Hi all,

As you've probably seen, I've published another update<https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20> to the JSCalendar draft with the changes discussed at the interim IETF meeting/CalConnect last week. A quick summary of the changes:

  *   Added Location#categories property
  *   Added Participant#scheduleAgent property
  *   Added Participant#language property
  *   Removed Participant#attendance property (this maps to roles instead)
  *   Made Participant#sendTo optional
  *   Made Alert#trigger mandatory

Daniel, could you please restart the last call; I think two weeks should be sufficient given how extensively this draft has already been reviewed over the years!

Cheers,
Neil.

---

From: Marten Gajda <[email-masked]>
Date: Fri, 18 Oct 2019 11:49:47 +0200

Hi all,

I've just read the current draft and had a few minor nitpicks, see below.

4.1.4.  prodId 
(https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.1.4)

In this context, what is the JSCalendar object? Is it the JSON object 
(or its serialized form) I'm currently looking at or is it the calendar 
entity that is represented by this JSON object?

To put it in other words, should a JSCalendar serializer always insert 
its own "prodId" when serializing an internal representation to a 
JSCalendar JSON file (even if no data was changed)?

Or is this related to the "updated" field? Should you only update 
"prodId" when you also update "updated"?

4.3.2.  recurrenceRule 
(https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.3.2)

The limits mentioned for "byMonth", "byMonthDay" and "byYearDay" are 
specific to the Gregorian calendar scale, e.g

> Valid values are 1 to 31 or -31 to -1
>
But other calendar scales may other limits. We should make clear that 
the limits depend on the maximum values of the respective calendar scale 
and maybe add "for Gregorian calendars the valid values are 1 to 31 or 
-31 to -1".

4.3.2.1.  Interpreting recurrence rules 
(https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.3.2.1)

> which defaults to gregorian if omitted.
gregorian should be quoted, I guess.

It may also be worth stating explicitly that the "skip" parameter only 
affects "yearly" and "monthly" rules (IIRC RScale didn't address 
ambiguous/invalid times during daylight saving changes)

In this paragraph:

>   If a skip property is defined and is not "omit", there may be
>         candidates that do not correspond to valid dates (e.g. 31st
>         February in the gregorian calendar).  In this case, the
>         properties MUST be considered in the order above and:
Gregorian should be capitalized.

Regards,

Marten

Am 15.10.19 um 20:03 schrieb Daniel Migault:
> The WGLC will end on October 30. Please review the document and 
> provide your feed back on the mailing list. All feed back are useful 
> for our AD to move the work forward.
>
> Yours,
>
> Daniel
>
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20>
>
> *From:* calsify <[email-masked]> *On Behalf Of *Neil Jenkins
> *Sent:* Tuesday, October 15, 2019 11:56 AM
> *To:* [email-masked]
> *Subject:* [calsify] Request to start last call for JSCalendar
>
> Hi all,
>
> As you've probably seen, I've published another update 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20> to the 
> JSCalendar draft with the changes discussed at the interim IETF 
> meeting/CalConnect last week. A quick summary of the changes:
>
> *Daniel*, could you please restart the last call; I think two weeks 
> should be sufficient given how extensively this draft has already been 
> reviewed over the years!
>
> Cheers,
>
> Neil.
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
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: Wed, 23 Oct 2019 17:01:43 +1100

Thanks for the review Marten.

> 4.1.4. prodId (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.1.4)

> In this context, what is the JSCalendar object? Is it the JSON object (or its serialized form) I'm currently looking at or is it the calendar entity that is represented by this JSON object?

> To put it in other words, should a JSCalendar serializer always insert its own "prodId" when serializing an internal representation to a JSCalendar JSON file (even if no data was changed)?

> Or is this related to the "updated" field? Should you only update "prodId" when you also update "updated"?

I think this should be whatever client last updated the event; so yes, only updating "prodId" when you also update the "updated" timestamp (which you should do whenever you make changes) is a neat way to describe it. I'll update the spec.

> 4.3.2. recurrenceRule (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.3.2)

> The limits mentioned for "byMonth", "byMonthDay" and "byYearDay" are specific to the Gregorian calendar scale, e.g

> But other calendar scales may other limits. We should make clear that the limits depend on the maximum values of the respective calendar scale and maybe add "for Gregorian calendars the valid values are 1 to 31 or -31 to -1".

Thanks, I have clarified this (I presume you meant byWeekNo instead of byMonth).

> 4.3.2.1. Interpreting recurrence rules (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-20#section-4.3.2.1)

> gregorian should be quoted, I guess.

Sure.

> It may also be worth stating explicitly that the "skip" parameter only affects "yearly" and "monthly" rules (IIRC RScale didn't address ambiguous/invalid times during daylight saving changes)

Sure, I've noted in the definition of the skip property that it only has an effect if the frequency is "monthly" or "yearly".

> Gregorian should be capitalized.

Thanks, done.

Cheers,
Neil.

---

From: Michael Douglass <[email-masked]>
Date: Wed, 23 Oct 2019 13:33:31 -0400

Section 8.3.2 appears to have the wrong text:

8.3.2.  Initial Contents for the JSCalendar Properties Registry

should be

8.3.2.  Initial Contents for the JSCalendar Types Registry

---

From: Michael Douglass <[email-masked]>
Date: Wed, 23 Oct 2019 15:24:04 -0400

and in section 8.2.6 categories shows up twice in the table. Was that 
intended?

On 10/23/19 13:33, Michael Douglass wrote:
>> should be sufficient given how extensively this draft has already 
>> been reviewed over the years!
>>
>> Cheers,
>>
>> Neil.
>>
>>

---

From: Michael Douglass <[email-masked]>
Date: Wed, 23 Oct 2019 16:05:52 -0400

> and in section 8.2.6 categories shows up twice in the table. Was that 
and also "status"

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 24 Oct 2019 14:38:44 +1100

> 8.3.2. Initial Contents for the JSCalendar Types Registry

Thanks, fixed.

>> and in section 8.2.6 categories shows up twice in the table. Was that intended?

> and also "status"

Yes, this is intentional. The property context is different between them and they have different definitions.

Cheers,
Neil.

---

From: Michael Douglass <[email-masked]>
Date: Thu, 24 Oct 2019 16:47:18 -0400

In section 6.8 should the localization example have @type

On 10/23/19 23:38, Neil Jenkins wrote:
> Yes, this is intentional. The property context is different between 
> them and they have different definitions.

I'd prefer one of them had been called scheduleStatus. Can't validate 
the value without the context

Also I feel categories for locations would have been better as locationType

---

From: Michael Douglass <[email-masked]>
Date: Thu, 24 Oct 2019 23:40:34 -0400

I'm implementing this so I may have more...

Section 6.3 - simple group -

Is that example correct? The definition of entries say's

A collection of group members.  This is represented as a map of the
"uid" property value to the JSCalendar object member having that uid.

but the example just looks like an array. Is it supposed to be

{
   "@type": "jsgroup",
   "uid": "2a358cee-6489-4f14-a57f-c104db4dc343",
   "updated": "2018-01-15T18:00:00Z",
   "name": "A simple group",
   "entries": {
     "2a358cee-6489-4f14-a57f-c104db4dc2f1": {
       "@type": "jsevent",
       "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1",
       "updated": "2018-01-15T18:00:00Z",
       "title": "Some event",
       "start": "2018-01-15T13:00:00",
       "timeZone": "America/New_York",
       "duration": "PT1H"
     },
     "2a358cee-6489-4f14-a57f-c104db4dc2f2": {
       "@type": "jstask",
       "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2",
       "updated": "2018-01-15T18:00:00Z",
       "title": "Do something"
     }
   }
}

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 25 Oct 2019 17:08:15 +1100

> In section 6.8 should the localization example have @type 

No, it's a map of type `String[PatchObject]`, not its own type.

> I'd prefer one of them had been called scheduleStatus. Can't validate the value without the context

I think you're always going to need the context to validate properly. The status property in RFC5545 <https://tools.ietf.org/html/rfc5545#section-3.2.12> is basically the same. It's not really the scheduleStatus, it's the event/task status.

> Also I feel categories for locations would have been better as locationType

Sure, I'll change that.

> Is that example correct?

No!

>  Is it supposed to be … [elided] …

Yes! I'll fix that.

Cheers,
Neil.

---

From: Michael Douglass <[email-masked]>
Date: Fri, 25 Oct 2019 12:01:48 -0400

On 10/25/19 02:08, Neil Jenkins wrote:
> No, it's a map of type |String[PatchObject]|, not its own type.
>
What I meant was that the objects in the list should have a type:

      "localizations": {
        "de": {
          "@type": "PatchObject"                    <------------------- this
          "title": "Live von der Music Bowl: The Band!",
          "description": "Schau dir das groesste Musikereignis an!",
          "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name":
                                  "Gratis Live-Stream aus der Music Bowl"
        }
      }

I think patch objects are the only objects that don't have a type. I 
think for simplicity and ease of validation all objects should be 
required to have @type

---

From: Michael Douglass <[email-masked]>
Date: Fri, 25 Oct 2019 12:17:10 -0400

On 10/25/19 02:08, Neil Jenkins wrote:
> I think you're always going to need the context to validate properly. 
> The status property in RFC5545 
> <https://tools.ietf.org/html/rfc5545#section-3.2.12> is basically the 
> same. It's not really the scheduleStatus, it's the event/task status.
>
So the status in 5.1.3 and 5.2.6 is essentially the status in rfc 5545

Then we have participationStatus in 4.4.5 which comes from 5545 partstat 
with

       *  "needs-action": No status yet set by the participant.
       *  "accepted": The invited participant will participate.
       *  "declined": The invited participant will not participate.
       *  "tentative": The invited participant may participate.

But we also have in 5.2.5 participantProgress with a status property:

       *  "completed": The participant completed this task.
       *  "in-process": The participant has started this task.
       *  "failed": The participant failed to complete this task.

Those values are essentially the partstat values from 5545 - so now we 
could have a participationStatus of declined and a 
participantProgress/status of completed which doesn't make any sense.

I like the idea of the participantProgress object but maybe it should be 
common to all and the participantStatus should be moved there. The task 
specific part should define the allowable set of values as 5545 does.

---

From: Michael Douglass <[email-masked]>
Date: Fri, 25 Oct 2019 22:38:35 -0400

Table in section 8.2.6 appears to be missing an entry for links

---

From: Michael Douglass <[email-masked]>
Date: Sat, 26 Oct 2019 00:25:36 -0400

> Table in section 8.2.6 appears to be missing an entry for links
and locale

---

From: Michael Douglass <[email-masked]>
Date: Sat, 26 Oct 2019 16:51:42 -0400

>> Table in section 8.2.6 appears to be missing an entry for links
and frequency

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 28 Oct 2019 11:28:44 +1100

"de": {
> 
> I think patch objects are the only objects that don't have a type. I think for simplicity and ease of validation all objects should be required to have @type

No. The `@type` property is for objects with a named set of attributes (essentially a class). The PatchObject is a primitive datatype, more like Integer etc. There are no predefined keys; each key is a patch to apply. So if you add `@type` there, that's actually a path to overwrite the `@type` property on the object you apply it to!

On Sat, 26 Oct 2019, at 03:17, Michael Douglass wrote:
> Then we have participationStatus in 4.4.5 which comes from 5545 partstat with

> 
> Those values are essentially the partstat values from 5545 - so now we could have a participationStatus of declined and a participantProgress/status of completed which doesn't make any sense.

> I like the idea of the participantProgress object but maybe it should be common to all and the participantStatus should be moved there. The task specific part should define the allowable set of values as 5545 does.

I agree this is confusing. Looking at it, I think the best thing is to rename the "status" property on the JSTask to "progress", and use the same property on a Participant (no need for a whole complex object like we currently have). This makes it consistent again: the same property name means the same semantics, different property name means different allowed values and semantics. If that description is a bit hard to follow, see the diff here <https://github.com/CalConnect/PUBLIC_DRAFTS/commit/3546a6a8d9ded46185b1bb96a5a693353d16d360>, or look at the diff in the new revision.

> >> Table in section 8.2.6 appears to be missing an entry for links

Thanks, fixed. I've also added "uri" from VirtualLocations and all of the other RecurrenceRule props. I think I've checked them all now!

Since there have been quite a few fixes, I've published a new draft <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-21> with all the changes. Thanks for all the great feedback Mike!

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Sun, 27 Oct 2019 23:19:19 -0400

Thanks for the changes below - I'll adjust my code and may be back with 
more on them.

I do have another concern:

5545 decided to deprecate multiple recurrence rules on the grounds 
clients (by which is meant UIs) don't support it.

This spec doesn't even make provision for it.

I've long felt that standards and data models shouldn't be driven solely 
by the needs or preferences of UI designers.

However, I also believe that multiple recurrence rules provide either a 
simpler way or the only way to express some of the situations i come 
across i public events. For example, I found a user had created 7 
identical recurring events to cover tours of a campus which occur at 
different times and with different patterns through the week. It's 
relatively easy to figure out how to accommodate that in the UI (a 
button to add another recurrence section).

It was however a lot of work to update all those events and keep them 
the same.

I've been considering supporting multiple rules to support this use case 
as I suspect it's not that uncommon.

Even when it's possible to create some complex rule it might well be 
easier to create a number of simple rules.

There's also the possibility of using standard calendar data to control 
processes.

I suspect current libraries already support multiple rules and I'd like 
to see that enabled in this spec.

I understand that if they turn up in a client they may not be able to 
render them but we're already in that position with a sufficiently 
complex single rule (often not all that complex)

On 10/27/19 20:28, Neil Jenkins wrote:
> No. The |@type| property is for objects with a named set of attributes 
> (essentially a class). The PatchObject is a primitive datatype, more 
> like Integer etc. There are no predefined keys; each key is a patch to 
> apply. So if you add |@type| there, that's actually a path to 
> overwrite the |@type| property on the object you apply it to!
>
>> Those values are essentially the partstat values from 5545 - so now 
>> we could have a participationStatus of declined and a 
>> I like the idea of the participantProgress object but maybe it should 
>> be common to all and the participantStatus should be moved there. The 
>> task specific part should define the allowable set of values as 5545 
>> does.
>>
>
> I agree this is confusing. Looking at it, I think the best thing is to 
> rename the "status" property on the JSTask to "progress", and use the 
> same property on a Participant (no need for a whole complex object 
> like we currently have). This makes it consistent again: the same 
> property name means the same semantics, different property name means 
> different allowed values and semantics. If that description is a bit 
> hard to follow, see the diff here 
> <https://github.com/CalConnect/PUBLIC_DRAFTS/commit/3546a6a8d9ded46185b1bb96a5a693353d16d360>, 
> or look at the diff in the new revision.
>
> Thanks, fixed. I've also added "uri" from VirtualLocations and all of 
> the other RecurrenceRule props. I think I've checked them all now!
>
> Since there have been quite a few fixes, I've published a new draft 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-21> with all 
> the changes. Thanks for all the great feedback Mike!
>
> Neil.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 28 Oct 2019 00:36:13 -0400

> overwrite the |@type| property on the object you apply it to!
I still don't agree.

There's no way this is a primitive type. It's an object whichever way 
you look at it. The fact there are no predefined keys is an attribute of 
the pathObject class. Without the @type I have to defer any validation 
until the whole structure is parsed - or - for this one case only - I 
have to pass down the expected type.

As for the @path - In section 4.3.3 (version 21) for recurrence 
overrrides we have

    A pointer in the PatchObject MUST be ignored if it starts with one of
    the following prefixes:

    o  @type
and a bunch more

I think we could make that ignoring @path a general rule for pathObjects 
- is there anywhere we want to allow changing the type?

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 28 Oct 2019 15:55:29 +1100

On Mon, 28 Oct 2019, at 15:36, Michael Douglass wrote:
> As for the @path - In section 4.3.3 (version 21) for recurrence overrrides we have

   the following prefixes:

   o  @type
and a bunch more

That's just to do with the application of the patch in this instance, not an inherent attribute of the PatchObject. The PatchObject is used generically in JMAP RFC8620, Section 5.3 <https://tools.ietf.org/html/rfc8620#section-5.3>, and it makes no sense for it to have properties that are not patches; that would mean semantically "every key in this object is a patch except if it's this special value", which would be horrible to work with.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 28 Oct 2019 01:17:53 -0400

On 10/28/19 00:55, Neil Jenkins wrote:
> That's just to do with the application of the patch in this instance, 
> not an inherent attribute of the PatchObject. The PatchObject is used 
> generically in JMAP RFC8620, Section 5.3 
> <https://tools.ietf.org/html/rfc8620#section-5.3>, and it makes no 
> sense for it to have properties that are not patches; that would mean 
> semantically "every key in this object is a patch except if it's this 
> special value", which would be horrible to work with.

Well my experience in implementing it is the reverse. Having the @type 
simplifies things considerably.

However - in the absence of any other input (an invitation for anybody 
else to state an opinion on either side) I'll live with it.