Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt

From: Michael Douglass <[email-masked]>
Date: Thu, 2 Apr 2020 19:06:27 -0400

I have to apologize for the lateness of these issues I want to raise but 
I've started implementing the mapping of icalendar to JSCalendar and I'm 
already running into some problems.

I've only looked at a few properties so far.

In general - while I initially thought an informational spec would be 
fine for describing the mappings - I'm now of the opinion it has to be 
mandated where possible. Otherwise we're going to have a whole mess of 
incompatible implementations.

Privacy <-> CLASS

The first was the use of "secret" instead of "confidential" for the 
privacy property. The result is that a simple conversion to lowercase 
for jscalendar isn't sufficient. I know neither authors want to change 
at this late stage but I mention it (again) because this will be a 
perpetual annoyance.

link <->ATTACH, IMAGE, URL

ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL 
doesn't.

The description of rel has this:

   Links with a rel of "describedby" SHOULD be considered by the
       client to be an alternative representation of the description.

Is that supposed to be the same as URL - it doesn't match the 
description for URL in 5545?

I think the spec needs to explicitly state that URL MUST be represented 
by a link with a given rel - I'd suggest "alternate" because that seems 
closer to what is intended in 5545.

comments <-> COMMENT

comments is only specified for timezone rules. It needs to be valid for 
all or some indication of how to handle them needs to be provided.

There is an issue in 5545 with COMMENT in scheduling e.g. is a comment 
meant only for the organizer? That could be tightened up.

GEO, PERCENT-COMPLETE

What are we supposed to do with these?

updated <-> DTSTAMP, LAST-MODIFIED

I don't understand why 5545 has 2 values - however I think we need a 
better statement of how to map 2 values on to 1 - something about the 
later of the 2?

More to follow...

On 3/7/20 21:56, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Calendaring Extensions WG of the IETF.
>
>          Title           : JSCalendar: A JSON representation of calendar data
>          Authors         : Neil Jenkins
>                            Robert Stepanek
> 	Filename        : draft-ietf-calext-jscalendar-26.txt
> 	Pages           : 77
> 	Date            : 2020-03-07
>
> Abstract:
>     This specification defines a data model and JSON representation of
>     calendar data that can be used for storage and data exchange in a
>     calendaring and scheduling environment.  It aims to be an alternative
>     and, over time, successor to the widely deployed iCalendar data
>     format, and to be unambiguous, extendable, and simple to process.  In
>     contrast to the jCal format, which is also JSON-based, JSCalendar is
>     not a direct mapping from iCalendar, but defines the data model
>     independently and expands semantics where appropriate.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-26
> https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Fri, 3 Apr 2020 17:29:23 -0400

Further comments below

On 4/2/20 19:06, Michael Douglass wrote:
>
> I have to apologize for the lateness of these issues I want to raise 
> but I've started implementing the mapping of icalendar to JSCalendar 
> and I'm already running into some problems.
>
> ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but 
> URL doesn't.
>
> I think the spec needs to explicitly state that URL MUST be 
> represented by a link with a given rel - I'd suggest "alternate" 
> because that seems closer to what is intended in 5545.
>
>
> comments <-> COMMENT
>
> comments is only specified for timezone rules. It needs to be valid 
> for all or some indication of how to handle them needs to be provided.
>
CONTACT

There's no mapping suggested. CONTACT is vital for event publication. 
I'd suggest following the approach in eventpub - add a participantType 
property to participant

participantTypes: "String[Boolean]" (mandatory)

Defines the type of participation in
events or tasks.  Participants can be individuals or
organizations, for example attendees, a soccer team, the spectators, or the
musicians.

       At least one type MUST be specified for the participant.  The keys
       in the set MUST be one of the following values, a value registered
       in the IANA JSCalendar Enum Registry, or a vendor-specific value:

       *  "attendee": A participant attending a meeting.

       *  "active": A participant taking an active role - for example a team
          member.

       * "inactive":  A participant taking an inactive part - for example an
       audience member.

       * "sponsor":  A sponsor of the event.  The order property may be used
         with this participant type to define the relative order of
         multiple sponsors.

       * "contact":  Contact information for the event.  The order property may
         be used with this participant type to define the relative order of
         multiple contacts.

       * "booking-contact":  Contact information for reservations or payment

       * "emergency-contact":  Contact in case of emergency

       * "publicity-contact":  Contact for publicity

       * "planner-contact:  Contact for the event planner or organizer

       * "performer":  A performer - for example the soloist or the accompanist.
       The order property may be used with this participant type to
       define the relative order of multiple performers.  For example,
       "order": 1 could define the principal performer or soloist.

       * "speaker":  Speaker at an event

Change the participant description:
...
    If this property is set with a participant type of "attendee", then the "replyTo" property of this calendar
    object MUST define at least one reply method.
...
    o  roles: "String[Boolean]" (mandatory for participantType = "attendee")

---

From: Michael Douglass <[email-masked]>
Date: Fri, 3 Apr 2020 18:55:01 -0400

On 4/3/20 17:29, Michael Douglass wrote:
>> fine for describing the mappings - I'm now of the opinion it has to 
>> be mandated where possible. Otherwise we're going to have a whole 
>> mess of incompatible implementations.
>>
>> Privacy <-> CLASS
>>
>> for jscalendar isn't sufficient. I know neither authors want to 
>> change at this late stage but I mention it (again) because this will 
>> be a perpetual annoyance.
>>
>> There is an issue in 5545 with COMMENT in scheduling e.g. is a 
>> comment meant only for the organizer? That could be tightened up.
>>
> CONTACT
>
Having looked again I thought this could probably be handled just by 
changing the wording for participant as I suggested and extending the 
roles values. However I think that's conceptually more complicated,

"participantTypes": {"attendee": true}

"roles": {"optional": true}

is easier to understand than

"participantTypes": {"optional": true}

implying this is an optional attendee.

Changing role "attendee" to "required" or "expected" might make sense

>     o  roles: "String[Boolean]" (mandatory for participantType = "attendee")

I've got another question on mapping:

In your mapping draft you say:

An iCalendar ORGANIZER maps to both the replyTo property and a
    participant with role "owner".  If an ATTENDEE with the same CAL-
    ADDRESS value exists, then it maps to the same participant as the
    ORGANIZER participant.

What if the attendee and organizer have different SENT-BY parameters? 
And what is SENT-BY mapped to?

I think the 2 ought to be kept separate.

---

From: "Tim Hare" <[email-masked]>
Date: Sat, 4 Apr 2020 22:36:28 -0400

As for DTSTAMP and LAST-MODIFIED,   RFC States

-------------------------------------------

   Property Name:  DTSTAMP

   Purpose:  In the case of an iCalendar object that specifies a

      "METHOD" property, this property specifies the date and time that

      the instance of the iCalendar object was created.  In the case of

      an iCalendar object that doesn't specify a "METHOD" property, this

      property specifies the date and time that the information

      associated with the calendar component was last revised in the

      calendar store.

   Property Name:  LAST-MODIFIED

   Purpose:  This property specifies the date and time that the

      information associated with the calendar component was last

      revised in the calendar store.

         Note: This is analogous to the modification date and time for a

         file in the file system.

So, when an item has a METHOD such as REQUEST then this is the time the object was created, NOT the time the object was last created in the calendar store.    If no METHOD is specified (this is not part of a scheduling flow, for example) then they serve the same purpose.   If I were creating files or objects I would use both in any case.

Tim Hare
Interested Bystander, Non-Inc.

From: calsify [mailto:[email-masked]] On Behalf Of Michael Douglass
Sent: Friday, April 3, 2020 6:55 PM
To: [email-masked]
Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt

Further comments below

I have to apologize for the lateness of these issues I want to raise but I've started implementing the mapping of icalendar to JSCalendar and I'm already running into some problems.

In general - while I initially thought an informational spec would be fine for describing the mappings - I'm now of the opinion it has to be mandated where possible. Otherwise we're going to have a whole mess of incompatible implementations.

Privacy <-> CLASS

The first was the use of "secret" instead of "confidential" for the privacy property. The result is that a simple conversion to lowercase for jscalendar isn't sufficient. I know neither authors want to change at this late stage but I mention it (again) because this will be a perpetual annoyance.

ATTACH and IMAGE seem fine (reltype of enclosure and icon resp.) but URL doesn't. 

Is that supposed to be the same as URL - it doesn't match the description for URL in 5545?

I think the spec needs to explicitly state that URL MUST be represented by a link with a given rel - I'd suggest "alternate" because that seems closer to what is intended in 5545.

comments <-> COMMENT

comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided.

There is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up.

CONTACT

There's no mapping suggested. CONTACT is vital for event publication. I'd suggest following the approach in eventpub - add a participantType property to participant

Having looked again I thought this could probably be handled just by changing the wording for participant as I suggested and extending the roles values. However I think that's conceptually more complicated, 

 

 

 

 

....
....

What if the attendee and organizer have different SENT-BY parameters? And what is SENT-BY mapped to?

 

GEO, PERCENT-COMPLETE

I don't understand why 5545 has 2 values - however I think we need a better statement of how to map 2 values on to 1 - something about the later of the 2?

More to follow...

On 3/7/20 21:56, [email-masked] <mailto:[email-masked]>  wrote:

 
Abstract:

 

_______________________________________________
calsify mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Sat, 4 Apr 2020 23:14:38 -0400

On 4/4/20 22:36, Tim Hare wrote:
> So, when an item has a METHOD such as REQUEST then this is the time 
> the object was created, NOT the time the object was last created in 
> the calendar store.    If no METHOD is specified (this is not part of 
> a scheduling flow, for example) then they serve the same purpose.   If 
> I were creating files or objects I would use both in any case.
>
> Tim Hare
Well - I saw the words but I couldn't figure out what the practical 
difference is. If there really is a practical difference and we should 
be setting these differently then it suggests the mapping in jscalendar 
needs to be revised.

There is a scheduleUpdated property in the participant - is that what 
corresponds to the itip usage of DTSTAMP?

> *From:*calsify [mailto:[email-masked]] *On Behalf Of 
> *Michael Douglass
> *Sent:* Friday, April 3, 2020 6:55 PM
> *To:* [email-masked]
> *Subject:* Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.txt
>
>         I have to apologize for the lateness of these issues I want to
>         raise but I've started implementing the mapping of icalendar
>         to JSCalendar and I'm already running into some problems.
>
>         In general - while I initially thought an informational spec
>         would be fine for describing the mappings - I'm now of the
>         opinion it has to be mandated where possible. Otherwise we're
>         going to have a whole mess of incompatible implementations.
>
>         Privacy <-> CLASS
>
>         The first was the use of "secret" instead of "confidential"
>         for the privacy property. The result is that a simple
>         conversion to lowercase for jscalendar isn't sufficient. I
>         know neither authors want to change at this late stage but I
>         mention it (again) because this will be a perpetual annoyance.
>
>         represented by a link with a given rel - I'd suggest
>         "alternate" because that seems closer to what is intended in 5545.
>
>         comments <-> COMMENT
>
>         comments is only specified for timezone rules. It needs to be
>         valid for all or some indication of how to handle them needs
>         to be provided.
>
>     There's no mapping suggested. CONTACT is vital for event
>     publication. I'd suggest following the approach in eventpub - add
>     a participantType property to participant
>
>         I don't understand why 5545 has 2 values - however I think we
>         need a better statement of how to map 2 values on to 1 -
>         something about the later of the 2?
>
>         More to follow...
>

---

From: Michael Douglass <[email-masked]>
Date: Sun, 5 Apr 2020 00:31:47 -0400

Date time issues.

The definition of the SUBSECOND parameter needs to be in the jscalendar 
spec. I'm not sure about the statement:

  SUBSECOND MUST NOT be used in date-
       time calculations or comparisons in  iCalendar.

The smart grid people were asking about having subseconds some time ago 
so the use of this parameter goes beyond just mapping. Also what about 
fractional values > 0.5? Really we should round to nearest? Would it be 
better to have e.g. a FRACTIONAL parameter with the whole date-time and 
allow the value to be the rounded value.?

On 4/3/20 18:55, Michael Douglass wrote:
>>> In general - while I initially thought an informational spec would 
>>> be fine for describing the mappings - I'm now of the opinion it has 
>>> to be mandated where possible. Otherwise we're going to have a whole 
>>> privacy property. The result is that a simple conversion to 
>>> lowercase for jscalendar isn't sufficient. I know neither authors 
>>> want to change at this late stage but I mention it (again) because 
>>> this will be a perpetual annoyance.
>>>
>> I'd suggest following the approach in eventpub - add a 
>> participantType property to participant
>>
>>> better statement of how to map 2 values on to 1 - something about 
>>> the later of the 2?
>>>
>>> More to follow...
>>>
>>>

---

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 30 Apr 2020 15:59:50 +0200

> The definition of the SUBSECOND parameter needs to be in the jscalendar spec. 

>From what I recall we agreed to define the iCalendar-JSCalendar specific mappings in the mapping RFC draft? And make that a standard document, rather than informational?

> 
> I'm not sure about the statement:

Yes, let's remove that statement.

> 
> [...] Also what about fractional values > 0.5? Really we should round to nearest? Would it be better to have e.g. a FRACTIONAL parameter with the whole date-time and allow the value to be the rounded value.?

As discussed in our call a couple of weeks ago, it would be best if we could just allow fractional seconds in DATE-TIME values. But that will break loads of iCalendar parser, so it will have to remain wishful thinking.

Both FRACTIONAL and SUBSECONDS have their flaws. I originally thought that the SUBSECONDS parameter is the better choice, but now that we talk about it, I come to prefer your FRACTIONAL idea.

We could define the FRACTIONAL parameter to contain the complete datetime including fractional seconds. A client that is aware of that parameter must both set the FRACTIONAL parameter and the date-time property value. The property value must contain the rounded value of FRACTIONAL. Time values with fractional seconds always round up to the next second. The value of the FRACTIONAL parameter must be ignored, if its rounded value does not match the property value.

What do you think?

Cheers,
Robert

---

From: Michael Douglass <[email-masked]>
Date: Thu, 30 Apr 2020 11:47:26 -0400

On 4/30/20 09:59, Robert Stepanek wrote:
> From what I recall we agreed to define the iCalendar-JSCalendar 
> specific mappings in the mapping RFC draft? And make that a standard 
> document, rather than informational?
Yes - my comment was an earlier though. If we're producing a 
standards=-track mapping it's fine there.
>> [...] Also what about fractional values > 0.5? Really we should round 
>> to nearest? Would it be better to have e.g. a FRACTIONAL parameter 
>> with the whole date-time and allow the value to be the rounded value.?
>>
>
> As discussed in our call a couple of weeks ago, it would be best if we 
> could just allow fractional seconds in DATE-TIME values. But that will 
> break loads of iCalendar parser, so it will have to remain wishful 
> thinking.
>
> Both FRACTIONAL and SUBSECONDS have their flaws. I originally thought 
> that the SUBSECONDS parameter is the better choice, but now that we 
> talk about it, I come to prefer your FRACTIONAL idea.
>
> We could define the FRACTIONAL parameter to contain the complete 
> datetime including fractional seconds. A client that is aware of that 
> parameter must both set the FRACTIONAL parameter and the date-time 
> property value. The property value must contain the rounded value of 
> FRACTIONAL. Time values with fractional seconds always round up to the 
> next second. The value of the FRACTIONAL parameter must be ignored, if 
> its rounded value does not match the property value.
>
> What do you think?

This seems a simpler approach. I know at least ical4j rounds subseconds 
values so there's not much work to be done other than provide the parameter.

I'll update the mapping.

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 01 May 2020 14:02:01 +1000

On Sun, 5 Apr 2020, at 13:14, Michael Douglass wrote:
> There is a scheduleUpdated property in the participant - is that what corresponds to the itip usage of DTSTAMP?

Yes. This is the only case where the two differ: in the iMIP response it's when the invitee set their RSVP as opposed to when the organiser last updated the event. The organiser actually needs to store this per-attendee anyway to be able to process iMIP messages properly, so we added an explicit property for this in JSCalendar.

Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 01 May 2020 14:11:08 +1000

> And what is SENT-BY mapped to?

Hmm, we don't have a mapping for SENT-BY, but this could be easily added as an extra property on the participant object (does anyone know if this is used in the wild out of interest?).

> What if the attendee and organizer have different SENT-BY parameters?

You could make this property multi-valued I guess, to record anyone that has acted as the participant at different points during the event's history.

Neil.