Minutes IETF106: calext
minutes-106-calext-00

IETF106 CALEXT WORKING GROUP AGENDA - 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