Skip to main content

Minutes IETF109: calext
minutes-109-calext-00

Meeting Minutes Calendaring Extensions (calext) WG
Title Minutes IETF109: calext
State Active
Other versions plain text
Last updated 2020-11-19

minutes-109-calext-00
# IETF 109 Calext session
16:00-18:00 ICT (UTC +7) Thursday Session III

* we have a 2 hour slot, but only asked for 1 hour!

[Calendar](https://datatracker.ietf.org/meeting/109/session/28342.ics)
[IETF 109 agenda](https://datatracker.ietf.org/meeting/109/agenda)
[Meetecho](https://meetings.conf.meetecho.com/ietf109/?group=calext&short=&item=1)
[Material](https://datatracker.ietf.org/meeting/109/session/calext)

# Agenda

Intro and Note Well: 5 min

Submitted documents: 10 min

* draft-ietf-calext-eventpub-extensions
* draft-ietf-calext-jscalendar
* draft-ietf-calext-valarm-extensions
* draft-ietf-calext-ical-relations

Discussion of current work items: 40 min

* draft-ietf-calext-jscalendar-icalendar - 15 min
* Mike's various docs - 25 min
 - icalendar-series
 - eventpub
 - subscription upgrade
 - vpoll

Milestone review: 5 min

# NOTES:

### eventpub:
* it's been waiting a long time!  How do we avoid that?  Shepherds push more!
* Ideally react ASAP to AD/reviewer feedback so they don't switch out.
* Mike: was tracking mailing list more than datatracker, wasn't aware that
there was stuff hanging on him. * Barry: have talked about this with the tools
team.  Some people would love to have datatracker send reminders.  Others get
iritated. * Working with tools team on coming up with a good answer and having
a flag in the data tracker for who the action is waiting on.

### jscalendar:
* Barry is ready to click approve if that's the right thing to do.
* Daniel - yep, it's ready to go.
* Going to approved right now!
* Need to wait for IESG telechat.

### valarm-extensions:
* awaiting approval from Apple
* Question for Barry: what can we do with unresponsive author?
* BCP79 says "your personal knowledge", so Cyrus should be able to respond.
* Barry: can't just remove Cyrus' name if he was an integratal part of it.
* Ken: Cyrus authored other icalendar drafts and we didn't have this problem
with legal.

ACTION: Daniel to follow up with Cyrus Daboo.

### ical-relations:

* Bron to just submit, no objections

ACTION: Bron to submit

## current drafts

### icalendar-jscalendar:
* mostly down to Mike now.
* Neil came up with a suggestion which Mike didn't respond to, but will work.
* Mike got caught up in software upgrades.  Going to pick up on it again soon.
* Hoping it will be wrapped up in a few weeks!

* Robert S: there are some changes still pending.
    * The spec still includes the old definition of the fractional icalendar
    parameter, need to update that. * Should wait until we've verified
    jscalendar to icalendar translation.  Not sure we're covering preservation
    of IDs. * Also need to cross check spec against Fastmail operations.

Probably January/February -> so look for March next year for WGLC.

ACTION: Mike to finish reviewing in the next few weeks.
ACTION: Robert to keep working on too.

## mike's drafts!

### series:

* went back through comments from Neil and Martin
* will need to make siginficant changes:
    * Master component.
    * Generated components will start including the master component.  Clients
    that don't know about it don't need to know. * Think this is better

* SRULE vs RRULE.
    * Stay with SRULE.
    * Adds no complexity, just a new property with different params.
    * Can create multiple recurrences.

* Hoping to implement it soon!  (ical4j)
* Nobody else has volunteered yet -> guess we need to push someone else to do
it.

* Ken will add things to libical.  Probably don't need it at Fastmail.

In Mike's situation with public events, can switch and nobody will know the
difference, will just make things a little faster.  Can use it without wider
adoption.

* Bron: challenge is when to generate events.
* Mike: you can always go ahead and generate the whole lot!

ACTION: Mike to update and WGLC soon

### eventpub:
* see above!  Something did come up in the list about eventpub.  Mostly
typographical errors. * Message from Dilyan * Re-casting STRUCTURED-LOCATION as
a VLOCATION component made sense.  Could contain encoded vcard, etc.  Or
reference a VCARD. * Mike inherited all this from Cyrus Daboo.  Makes sense to
turn location into a component with structured data inside it, with the VCARD
as a data URI. * Hate to be churning it at this late stage. * Matches better
with JSCalendar where it's a component. * Daniel: think that's fine. * Mike
thinks it can be done in a few days.

* Barry: does it need another review and consensus?  Chairs don't think so.
* So... OK then.  Mike will update the doc.

ACTION: Mike to email the list saying "here's what's going to be changed"
ACTION: Mike to upload a new version of EVENTPUB with this plus the minor fixes.

### subscription upgrade

* Only issue raised "what's the big advantage?"
* For mobile: reduce the amount of network traffic.
* Just need to finish text and resubmit.

ACTION: Mike will upload new draft.
ACTION: Bron to do WGLC on the new draft.

### vpoll

* still issues with the draft regarding itip interactions.
* Mike: made heavy changes to replace VVOTOR with the PARTICIPANT component
from eventpub.  Relies on eventpub going through. * This is a much better
approach, more compatible with jscalendar. * Need to fix up our
implementations.  Mike and Ken will test again. * unlikely to be done until mid
next-year. * Probably want to do a jscalendar version too.

ACTION: more testing

### serverside subscriptions (not on agenda):

* Mike/Ken: were hoping to sync this up with what Apple have deployed.  Will
follow up.

ACTION: Mike/Ken to follow up with Apple

### scheduling controls
* May be worth talking to Hans-Joerg.
* Given the push within the EU to allow import/export, this would make sense.

ACTION: Bron to follow up on and submit an updated document

MILESTONE:
* valarm -> Dec
* jscalendar -> DONE
* scheduling controls - Jan
* js-i: March
* serverside subscriptions: hopefully March
* vpoll: July

Finished in 48 min.