* 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: Francesca Palombini, Murray Kucherawy | 2014-Aug-28 —  

IETF-112 calext minutes


minutes-112-calext-00 minutes

          # CALEXT at IETF112
          Agenda Bash:
          Mike: nothing changed for the drafts in progress since the interim.
          Relations will probably take a little longer.
          ## Relations
          ### slide 2 - XML Reference
          Mike: couldn't find anything to lazily copy and paste from elsewhere.
          Found blog entries, but the XML specs don't appear to have anything like
          a security section.
          Does anybody have any ideas?
          Daniel: was the comment something generic?
          Mike: yes, since we're pointing at XML we should say something about
          the security issues in it.
          ### slide 3 - LINK relations
          Mike: think he just needs to create a mapping - don't think you need
          a registry.
          Bron: yeah, it just creates more work.
          Mike: did define a SOURCE relation, it's one of the things we're missing
          in icalendar (where did this thing come from originally).  There is
          something for the VCALENDAR object, but nothing for where to find a
          live copy.  This is useful in event publication.
          Think just need to be more explicit that it's a serialisation of the
          LINK header, and specify that LABEL=TITLE and FMTTYPE=TYPE.
          Think we don't need 'title*' etc.
          ### slide 4 - useful relations
          There was a discussion in CALCONNECT a long time ago at putting copyright
          info into events.
          There's a bunch of stuff "related" as well, which seems to overlap with
          some of the other relations?
          Think there's a lot that we can use.
          Don't think this should hold things up.
          Ken: agree with Bron/Mike don't need to define our own registry.  We do
          have a serialisation.
          Ken: for title* - think that's for non-ASCII, and since we're UTF-8 we
          don't have to worry about that.
          Mike: can say that.
          Bron/Ken: the XML stuff looked fine, but we're not security experts in
          XML.  Mike: it was more just "have to point out that there are security
          things to think about"
          Mark Nottingham noted that it references 8288, but so does JSCalendar -
          so maybe we need some errata there.
          ACTION: Neil to follow up with Mike on JSCalendar errata for RFC8288.
          ACTION: Mike will get out a new relations draft in the next few days.
          ## ical tasks
          Mike hasn't done anything in the last few weeks.
          This has been lying dormant for a long time.  The world has changed a bit.
          When you have a task being carried out by multiple actors, want to have
          a status per actor (attendee/participant).  Had a group parameter because
          we were scared of having new compontents, but we have participant now.
          Think we should introduce a new component which groups the more complex
          status data.
          ACTION: Mike has lots of work to do for ical-tasks
          ## jscalendar-icalendar
          Robert: no progress made since the interim 1 month ago.  Still in
          the design phase for jscalendar to icalendar, though the other way is
          supported quite well already.
          Waiting for implementation experience.
          Mike: have been bogged down in a new release, but will push along with
          implementing the mapping too.  Will see if we can wrap up the spec.
          Link is also stuck up in relations work.  There are some dependencies
          ACTION: Mike and Robert to keep working together on jscalendar-icalendar
          ## subscription-upgrade
          No progress since last call.  A couple of things raised, matter of
          opinion.  Think it's in a good state.
          ACTION: Mike will have a last run through and refresh of
          subscription-upgrade before WGLC.
          # Next work
          ## vpoll
          Mike made updates on the spec to make use of the participant component
          rather than a separate VOTER.
          Haven't updated implementation fully.  Maybe just Cyrus needs updating
          as well.
          Ken hasn't updated Cyrus yet.
          ACTION: Mike will publish vpoll again, then Ken will update the Cyrus
          ## serverside-subscription
          Waiting on Apple.
          # Future work
          Ken and Mike have talked about 5545/5546 - due for a refresh.  17 verified
          errata on 5545, and many updates that could be rolled in.
          DMARC and IMIP - probably need new language on how to deal with
          invites/replies on someone else's behalf.
          Not sure if there's enough energy to take on that work right now.
          Mike: what we're lacking is a document which describes the calendaring
          data model, independent of representation.  You can disentagle from
          ICALENDAR (e.g. jscalendar maps to it).
          Rather than just bringing out a new unreadable document, we could
          consider producting a document that describes the calendaring data model!
          Still lots of work, but might be more valuable.
          Ken: sounds similar to what HTTPBIS did, splitting wire format from
          Mike: this is what they do in OASIS - platform indepenent data model,
          plus representation.
          People in the smart-grid world really like their UML diagrams.
          Bron: the challenge is finding people who want to do authoring.
          Mike: there is a data model specification that is partially done -
          a subset of icalendar, so it may be worth looking at that.
          Daniel: if I have to refer to the model I'll read jscalendar.  Who is
          the target for such a document?
          Mike: it's when you're manipulating the data, you have to go back to
          icalendar and itip.
          Neil: itip is different - if it's just the data model
          (jscalendar/icalendar) don't think a separate document is much clearer.
          The JSON is easily represntable in other ways.  Agree current ITIP is
          hard to understand properly.
          Bron: yeah, we want to have jscalendar as an alternative in ITIP/IMIP.
          Neil: can't do any new document right now.
          Ken: probably get current work off the table.  Might need a recharter.
          Francesca: having the same conversation in another working group, whether
          rechartering is needed because maintenance work is not explicitly stated
          in the charter.  IMO not needed, but prefer to check with the IESG.
          Bron: we should probably re-charter to say "we look after all these
          Daniel: if we don't have to recharter, that's great.  If we do, would
          be good to
          Francesca: that sounds good, the IESG would have a discussion about this
          becoming a maintenance wg.
          Barry: when we chartered the first time, thought it was just a small set
          of things that were coming in from CalConnect.  Agree that if we rechater,
          we should do it as a long-running group to deal with calendar stuff.
          Disagree with Francesca that it will necessarily be a big deal.  Think we
          should do it.
          Daniel: Barry - do you think we should recharter?  Barry: yes, if you
          think it's going to be long running.
          ACTION: Bron to look at text for calext recharter with Daniel.
          # MILESTONES
          Milestones were updated live - see current milestones for details

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