* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Calext Status Pages

Calendaring Extensions (Active WG)
Art Area: Barry Leiba, Adam Roach, Alexey Melnikov | 2014-Aug-28 —  
Chairs
 
 


IETF-106 calext minutes

Session 2019-11-18 1330-1530: Orchard - Audio stream - calext chatroom

Minutes

minutes-106-calext-00 minutes



          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
          
          



Generated from PyHt script /wg/calext/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -