[calsify] Minutes from today's meeting

["Bron Gondwana" <[e-mail]>]

Hi all, I've uploaded the minutes from today's meeting to the datatracker. I reproduce them below as well. Please note any action points at the top of this document and get on those!

Thanks,

Bron.

IETF106 CALEXT WORKING GROUP - Singapore 2019-11-18, 13:30-14:30

= AGENDA

Welcome, Notewell, Bluesheets, Agenda bashing: 5m
Current Drafts:
* eventpub: 5m
* jscalendar & interop doc: 10m
* subscription upgrade: 5m
* valarm extensions: 5m
* series: 10m
Proposed Drafts:
* vpoll: 10m
Milestone Review: 5m
Any other business: 5m

= ACTIONS*
*
*
*
*Bron:**
*
** Update milestones**
*
*
*
*Daniel:**
*
** talk to IANA this week about jscalendar registrations**
*
*
*
*Neil:**
*
** change jscalendar to have recurrenceRules**
*
*
*
*Mike:**
*
** update EVENTPUB to have initial data copied into event and URLs just for refreshing**
*
** define CALDAV better in subscription upgrade**
*
** keep working with Ken on VPOLL**
*
*
*
*Ken:**
*
** add geopriv text and documentation to VALARM**
*
** keep working with Mike on VPOLL*

= DETAILED NOTES

The meeting started with significant technical difficulties with both Ken Murchison and Mike Douglass having trouble getting reliable sound.

Meetecho suggests that Safari is only recently supported, and using Firefox or Chrome would be a better choice.

There was no agenda bashing.

== Eventpub

Barry:
* Clients often follow URIs
* This draft adds tons more URIs in places where it's common to dereference
* Would prefer to remove URIs entirely where not necessary
* In the alternative, strongly advise against their use and insist that the user be prompted before loading them.

Mike:
* URIs already exist in lots of places.
* Don't feel that eventpub is the right place to solve this, we should build a BCP.
* ICALENDAR already has the URI field

Barry:
* Agree this isn't the best place, but might need to block until we have BCP

Mike:
* Don't want to block, but happy to add strong text and commit to building BCP and have the eventpub doc reference "look for BCP when it arrives".

Neil:
* Main problem is the HTML description, because that will be loaded before display.

Mike:
* use case is thinks like "VCARD contains user info, look there rather than copying into the event".
* URI will point to the up-to-date version.

Neil:
* Generally - URIs should be a way to look up more detail or refresh, but initial information should be embedded in the event so it's useful without following URIs.
* Also means that the data won't change under you or disappear (Barry: or have malware put in place) so the event is self contained. (e.g. domain expires)
* That way, can prompt user to follow URIs for updated without hurting usability if they don't.

Daniel:
* Agree from a privacy standpoint - event shouldn't need to follow URIs to be usable.

ACTION: Mike to update draft to have initial data copied into the event and the URIs be a way to get updated data.

== JSCalendar

Neil:
* has been in last call for a while now
* good feedback received and has been included
* registries have been created

Daniel:
* have sent registries to IANA for review, will follow up with them

Neil:
* haven't done any work on translation doc for icalendar/jscalendar. Will get back to that once jscalendar is final.

Mike:
* I still want multiple RRULE support - the removal in 5545 was a mistake IMHO
* most clients will support it, because ical4j does, and most use it
* have customers with events that they need many of because a single RRULE can't describe the event
* event publishers need complexity even if average client creating a simple event doesn't

Neil:
* Not much support - clients won't set it
* Potential issue with server data model when pulling in ICS feeds and losing the recurrence.
* But: willing to put it in (change recurrenceRule to recurrenceRules and make it an array) even if just about everyone only does one value

ACTION: Daniel to talk with IANA this week while they're colocated.
ACTION: Neil to change recurrenceRule(s) and take it back to the list

== Subscription upgrade

Bron:
* Question about recurrences - does ANY mention of the UID invalidate all items with that UID.
- e.g. does sending UID METHOD:DELETED for just the UID delete all the recurrences as well?
* I argue yes, since we're mapping over CALDAV which stores all the records for a UID in a single file.
* Important to be clear on this, as otherwise clients could wind up with stale recurrences which were no longer mentioned on the server.

Neil:
* the draft has both GET extensions and references to auth and non-auth caldav, is that excessive?
* if we keep the caldav stuff, it needs to reference the RFCs and be better specified.

Mike:
* GET is useful for simple clients, but if CALDAV is also available, it's more powerful.
* would like to keep both
* will improve the text to reference RFCs and etc
* biggest gain is mobile clients

ACTION: Mike to define CALDAV details better and new draft will be discussed on the list

== VALARM extensions

Daniel:
* geopriv chairs advised us to send questions to mailing list
* expect it might be hard to find traction
* there is a geopriv framework, we should reference it and follow the recommendations
* on the flip side, if we do nothing people will just use GPS, and mostly this data is being stored to the same service where GPS data is also sent for maps, etc!

Alexey:
* the right thing is to state your assumptions in the draft, e.g
 - we know geopriv data is in here, but we assume it's going to a service which already gets the GEO data anyway
 - add limitations/risks and security section detailing how to be careful with the data
* this should help it progress

ACTION: Ken will add geopriv text and documentation of assumptions

== SERIES

Mike:
* background - orgs produce long running events where every recurrence is an override, which is very inefficient
* this is a different model which treats each as a separate event and links using relations back to a master event

Neil:
* idea is good, but the draft needs lots of work - shouldn't be in last call!

Mike:
* agree, that was a misunderstanding

Neil:
* needs details on WHO generates the separate events and when
* series master is not a member of the series -> how will that work with non-aware clients?
 - suggestion of different top-level type? What will clients do.
 - METHOD:SERIESMASTER?
 - BEGIN:VEVENTSERIESMASTER?
 - will clients ignore it? or crash? needs research

Daniel:
* how does this compare to RRULE?

Mike/Neil:
* it's for different situations - both are useful for different things
* RRULE good for "same thing happens every so often"

ACTION: discuss on list

== VPOLL

Mike:
* nearly finished convering to PARTICIPANT
* problem is document structure - should there be separate documents for different modes?

ACTION: Mike and Ken to continue iterating and discuss on list

== Milestones

* jscalendar - Dec 2019
* eventput - sent to IESG! TICK
* valarm - Dec 2019
* vpoll - Apr 2020
* series - Jun 2020


== Other business

tzdist:
* This was a private chat with Daniel which didn't happen on mic - but the conclusion was "let's do the same as with VALARM and document assumptions but keep progressing".
* goal: get IANA or similar to run a public canonical tzdist server

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [e-mail]