# 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.