Skip to main content

Minutes IETF112: calext
minutes-112-calext-00

Meeting Minutes Calendaring Extensions (calext) WG
Date and time 2021-11-10 14:30
Title Minutes IETF112: calext
State Active
Other versions plain text
Last updated 2021-11-14

minutes-112-calext-00
# 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