Subject: [calsify] draft-ietf-calext-jscalendar-26 and mappings to iCalendar

From: Michael Douglass <[email-masked]>
Date: Wed, 8 Apr 2020 22:37:05 -0400

Hi.

We had a call today to discuss where to go with the issue of mappings 
and we are in agreement that the mappings need to be a standards track 
document. Briefly the reasons are:

1. We need to mandate the mappings that should be used so that 
downstream services can reliably convert back.

2. These mappings may require the specification of properties and values 
(e.g. for LINK relationships) which can only be done in such a document.

My personal belief is that specifying the mappings should not take too 
long - very little of it needs to be controversial.

The question remains as to whether this should be

1. sections in the jscalendar spec or

2. a separate document.

Robert prefers option 1 because we are already a long way on in the 
process. I'll let him and others expand on that.

I prefer option 2 because if these mappings are a requirement they are 
much harder to miss and a little more convenient.

Additionally I think jscalendar MUST state that certain values (e.g. for 
link rel) are reserved for mapping to iCalendar and that leads to in 
effect the same situation - jscalendar has to wait for the mapping so it 
may as well be one document.

As for the mappings themselves - I have offered to help produce the 
content for the spec - wherever it lives and I will repost the issues I 
already posted as one message per issue to try to reduce the clutter

I hope this reflects the opinions of Robert and Ken - please correct me 
if not...

---

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 09 Apr 2020 08:54:11 +0200

Hi Mike,

On Thu, Apr 9, 2020, at 4:37 AM, Michael Douglass wrote:
> document

Yes, fully agree.

> much harder to miss and a little more convenient.

I think you got this wrong. I prefer option 2, whereas I understood you would prefer option 1? I prefer to define a mapping spec as a separate document, and keep the JSCalendar spec as-is.

> already posted as one message per issue to try to reduce the clutter

I'm happy you'll join as co-author. The (currently outdated) spec source is located at https://github.com/CalConnect/PUBLIC_DRAFTS/blob/master/jscalendar/draft-ietf-calext-jscalendar-icalendar.xml 

Cheers,
Robert

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 15 Apr 2020 13:31:42 +1000

I agree with Robert: this should remain a separate document. Both because the JSCalendar document is basically done and we'd really like to not hold it up further (it's taken forever) but more importantly it makes the document less intimidating for implementers that don't care about iCalendar, as they won't have a huge load of irrelevant (to them) complicated text to ignore.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Sun, 19 Apr 2020 16:12:28 -0400

On 4/14/20 23:31, Neil Jenkins wrote:
> I agree with Robert: this should remain a separate document. Both 
> because the JSCalendar document is basically done and we'd really like 
> to not hold it up further (it's taken forever)

jscalendar - 2yrs 8mths

rfc5545 - 4yrs

rfc5546 - 4yrs 2mths

caldav - 2yrs 8mths

caldav-scheduling - 7 years

eventpub - 9yrs and counting...

> but more importantly it makes the document less intimidating for 
> implementers that don't care about iCalendar, as they won't have a 
> huge load of irrelevant (to them) complicated text to ignore.

I'm not committed to one or the other but I do believe that doing this 
properly - and avoiding years of interoperability issues - is going to 
mean some changes to the jscalendar spec.

I don't think it needs to take long - at least to ensure that jscalendar 
is going to be correctly mappable.