Subject: [calsify] jscalendar and COMMENT

From: Michael Douglass <[email-masked]>
Date: Sun, 3 May 2020 21:36:16 -0400

Did we have any resolution to this?

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.

I understand 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 i 
guess. Still I need somewhere to put a COMMENT

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 06 May 2020 16:34:30 +1000

On Mon, 4 May 2020, at 11:36, Michael Douglass wrote:
> I need somewhere to put a COMMENT

We can add a simple plain text comment property; I'll do that. Note, we also have the participationComment property in the Participant object to store the comment you received in the last RSVP response.

Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 06 May 2020 16:42:16 +1000

> We can add a simple plain text comment property; I'll do that. Note, we also have the participationComment property in the Participant object to store the comment you received in the last RSVP resp…

Now I context switch this a bit more back into my memory: the intention was that you would put your comment directly in your Participant object when sending an RSVP (so if you had an iCalendar with METHOD=REPLY and a COMMENT, you would put that comment in the participant object of the CU sending the reply). Is there anywhere else this is really used? Because otherwise I think this just needs to go into the iCalendar mapping document.

Neil.

---

From: "Robert Stepanek" <[email-masked]>
Date: Wed, 06 May 2020 08:57:29 +0200

On Wed, May 6, 2020, at 8:34 AM, Neil Jenkins wrote:
> We can add a simple plain text comment property; I'll do that.

RFC 5545 allows for multiple COMMENT properties per calendar object. The TimeZone in the JSCalendar defines the comments properties as an array of String. I think we should do the same for JSEvent and JSTask (probably also for JSGroup).

Cheers,
Robert

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 11 May 2020 14:39:06 +1000

> RFC 5545 allows for multiple COMMENT properties per calendar object. The TimeZone in the JSCalendar defines the comments properties as an array of String. I think we should do the same for JSEvent…

I don't really understand what the semantics of multiple comments are meant to be; the only thing I can assume is that in iCalendar they were meant to be read in the context of the raw source file (e.g. you put the COMMENT just before DTSTART because you want to make a comment about the start time), but that's nuts because there's no way a client can represent that, and nobody does all their calendaring by just reading and writing raw source files: which goes back to my point, how is this actually being used at the moment? The goal with JSCalendar has always been to be a useful understandable data model first, 1:1 translation with 5545 second. What I don't want to do is make the new format worse just so you can map something weird that isn't really used from iCalendar.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 11 May 2020 01:06:21 -0400

We're going to have to live with iCalendar and manage a reasonably 
seamless translation between icalendar and jscalendar if we want it used.

Rather than try to determine who is using what in iCalendar - unless it 
is seriously broken - I think we should try to make that transition easy.

I doubt comments were meant to be read in the raw file - the specs gives 
a clue - from 5546:

    An "Attendee" MAY include a message to the "Organizer" using the
    "COMMENT" property.  For example, if the user indicates tentative
    acceptance and wants to let the "Organizer" know why, the reason can
    be expressed in the "COMMENT" property value.

I agree this is probably not implemented by many but it's there and some 
people probably use it.

If there's no good reason not to be compatible with 5545/6 we should be so.

On 5/11/20 00:39, Neil Jenkins wrote:
>> RFC 5545 allows for multiple COMMENT properties per calendar object. 
>> The TimeZone in the JSCalendar defines the comments properties as an 
>> array of String. I think we should do the same for JSEvent and JSTask 
>> (probably also for JSGroup).
>
> I don't really understand what the semantics of multiple comments are 
> meant to be; the only thing I can assume is that in iCalendar they 
> were meant to be read in the context of the raw source file (e.g. you 
> put the COMMENT just before DTSTART because you want to make a comment 
> about the start time), but that's nuts because there's no way a client 
> can represent that, and nobody does all their calendaring by just 
> reading and writing raw source files: which goes back to my point, how 
> is this actually being used at the moment? The goal with JSCalendar 
> has always been to be a useful understandable data model first, 1:1 
> translation with 5545 second. What I don't want to do is make the new 
> format worse just so you can map something weird that isn't really 
> used from iCalendar.
>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 11 May 2020 15:46:32 +1000

> If there's no good reason not to be compatible with 5545/6 we should be so.

Sure. My issue is that if we the authors can't explain how it's meant to be used, the chance of it being used in an interoperable way are close to none anyway.

> I doubt comments were meant to be read in the raw file - the specs gives a clue - from 5546:
>    the reason can be expressed in the "COMMENT" property value.

The use of "the" instead of "a" would indicate this author also would be surprised to see multiple COMMENT values.

My suggestion was to keep it single valued (because that at least makes more sense to me: it's a message attached to the event – if you were to use iMIP it's probably the same value you'd put in the email body itself). You can map multiple in from iCalendar by concatenating with one or two new lines in between – but it's slightly lossy, you wouldn't be able to tell it was multiple COMMENT values when mapping back to iCalendar.

Alternatively we can make it an array of values so it maps more cleanly, but then I think it will be more difficult to explain and cause more complexity pain for implementors in the future (they never want to use more than one value, but now always have to handle the possibility it could be multi-valued).

Neil.