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

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


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

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 documents".

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