Subject: [calsify] Updated JSCalendar draft calext-04

From: Robert Stepanek <[email-masked]>
Date: Fri, 25 May 2018 10:26:13 +0200

Hi all,

thanks for all your input on version 3 of the JSCalendar RFC draft. I
have just uploaded version 4[1] which incorporates your feedback.
Main changes:
 * *recurrenceRule and recurrenceOverrides*: the definition of
   recurrence rules and overrides has been refined. It now also includes
   the evaluation instructions as outlined by Neil.
 * *localizations*: following our conference calls and email discussion,
   the specification again includes the localizations property. However,
   it does not define how to maintain validity of localized content, nor
   does it define how to map them between iCalendar and JSCalendar.
 * *replyTo*: the HTTP path template for the replyTo `web` property must
   use HTTPS.
For the upcoming CalConnect conference in Tokyo in one week, I plan the
current version to be the basis for discussion. Depending on your
feedback on the list, we might send out a new version before the IETF
102 draft submission deadline on July 2.
Cheers,
Robert

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-04

---

From: Neil Jenkins <[email-masked]>
Date: Fri, 25 May 2018 06:43:10 -0400

The recurrenceOverrides type is now wrong. It should just be LocalDate[PatchObject]|null

Neil.

---

From: Robert Stepanek <[email-masked]>
Date: Fri, 25 May 2018 12:45:18 +0200

> LocalDate[PatchObject]|null
Meh, I knew I had overseen something. I'll fix it in the next version.

Thanks,
Robert

---

From: Michael Douglass <[email-masked]>
Date: Sun, 27 May 2018 17:46:54 -0400

I'm glad to see localizations feature replaced and i was supposed to 
provide the arguments in favor of doing so in advance - so I'll provide 
it anyway.

The lack of any multi-language support in the icalendar model is a 
significant issue. In many regions it is a legal requirement that some 
organizations - usually public/governmental - provide content in a 
number of languages - e.g. english and french or spanish and basque.

This is usually not a problem for communications within an enterprise 
where a single language is often mandated. It IS a problem in event 
publication.

This is not something that can be resolved by services doing language 
negotiation. An event may pass through a number of service - e.g. event 
aggregators - before being delivered to its final destination. At the 
end point of course - a service could choose to deliver the content in a 
single language. However we need a standard way of passing through the 
localized data.

Of course there are problems in workflow and how to ensure the different 
languages content is in synch. This is not our problem. We define the 
data model - it's up to applications to implement workflow and 
publication mechanism in whatever way is appropriate to them.

There have been many years of discussion on how to define a good data 
model and we finally seemed to have come to some agreement that a new 
LOCALIZATIONS component would be the best approach.

I strongly support such a feature being part of the base JSCalendar 
specification. iCalendar from its inception was strongly biased towards 
creating meetings in corporate enterprises. In fact in the early years 
of calconnect people continuously referred to them not as "events" but 
as "meetings".

Event publication and social calendaring have grown in importance over 
the years and it is incumbent on us as standards developers to support 
the needs of these communities or they will continue to use non or 
de-facto standards.

On 5/25/18 04:26, Robert Stepanek wrote:
> have just uploaded version 4 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-04> which 
> incorporates your feedback.
>
> Main changes:
>
>     recurrence rules and overrides has been refined. It now also
>     includes the evaluation instructions as outlined by Neil.
>   * *localizations*: following our conference calls and email
>     discussion, the specification again includes the localizations
>     property. However, it does not define how to maintain validity of
>     localized content, nor does it define how to map them between
>     iCalendar and JSCalendar.
>   * *replyTo*: the HTTP path template for the replyTo `web` property
>     must use HTTPS.
>
>
> For the upcoming CalConnect conference in Tokyo in one week, I plan 
> the current version to be the basis for discussion. Depending on your 
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify