# CALEXT Agenda - IETF115 London   {#calext-agenda---ietf115-london}

Date: Tue 8 Nov 2022  
Time 16:30-17:30 local (15:30-16:30 UTC)

## Agenda   {#agenda}

Intro and Notewell: 5 min

In last call:

*   subscription upgrade: 5 min

Existing drafts:

*   JSCalendar and friends: 10 min
*   JSContact and friends: 10 min
*   ICal Tasks: 10 min
*   VPoll: 5 min

Expired drafts: 5 min total

*   series
*   serverside subscriptions

Milestones: 5 min

AOB: 5 min

# Minutes   {#minutes}

Bron did the intro

## subscription upgrade   {#subscription-upgrade}

*   Outstanding questions to be solved... Ken and Mike had to look at
    spec to see what's valid for the "Vary" header.
*   Bron will send a quick review, Mike fix, Bron sent to IESG.

## jscalendar   {#jscalendar}

Robert presenting

*   mostly want to move forward with PARTICIPANT and only keep ATTENDEE
    for backwards compatibility.
*   still some heuristics. Don't like those for conversions, because
    they're always the things that implementations could get wrong.
*   need to look at iTIP, haven't started that. Have to make sure
    existing rules still stay for backwards compat.

*   would be very happy to have another author
*   would make sense to aim for IETF117 (July 2023) for WGLC.

*   we already have JMAP specifications waiting for jscalendarbis, don't
    have a proposal for how to deal with this in JMAP. Differences
    aren't that big, but especially for scheduling that rework needs to
    be taken into consideration.

Mike:

*   Biggest part of the mapping is the implementation. Actually doing it
    and noting
*   Most of this came from implementing and running into roadblocks.
*   Need more people to implement and test.

Robert:

*   agree

Ken:

*   can take some of the implementation load from Robert, and add to
    work on text.
*   See JMAP as just the protocol and jscalendar as the payload. Don't
    need to hold it up.

Mike:

*   all the testing I'm doing is over CalDAV, you don't need the
    protocol.

Agreement -> don't think they should be blocked.

Robert:

*   Don't think they might be blocked by waiting for definitions, but
    the specifiations refer to JSCalendar. If they get implemented as
    used, then we need to deal with the fact that there's jscalendar
    data out there with the current scheduling model rather than the BIS
    model

Joris:

*   see this as an issue. Potential issue, but at least for the tasks
    spec - probably won't be complete very soon. Wouldn't see it as an
    issue, just something we need to track.
*   Make sure jscalendar is in a final state before we publish jmap for
    calendars and jmap tasks.
*   Right now, implementing conversion spec for nextcloud (both
    directions)

Mike:

*   if we could express the requirement in a more abstract form (model
    rather than representation) that might help for future.

Robert:

*   if change in jscalendarbis, could make it backwards compat. Right
    now in jscalendar if you delegate to another participant, you use
    the artificial identifier for this participant.
*   In jscalendarbis model, need to rever to the URL which is scheduleid
    of another participant. If we make it "participantId OR URI" then it
    could work. ParticipantId can never be a URI because characters
    don't make a well formed URI.

Mike:

*   re-raises issue of why we don't have a version number!
*   Would resolve some of these issues, if you knew which version you
    could allow for these issues.

Robert:

*   Joris and I had this chat. Agree that version number we use for
    non-backwards-compat changes.

Mike:

*   We have a version in ICALENDAR but we never changed it, so nobody
    pays attention.

Robert:

*   Agree, should version in BIS

Daniel:

*   Question, problem if we wait for jscalendarbis before moving in
    JMAP?

Mike:

*   Need to push for getting more testing done.

Joris:

*   Regarding version number, it's probably just a key-value thing,
    don't see it hurting anyone.

Bron:

*   could just change the thing in `@type`.

Mike:

*   having a version which gets changed each time, can automatically
    fire off a conversion between versions.

Ken:

*   regarding whether JMAP should be blocked. Do we know if other
    implementors are waiting other than Fastmail.

Bron:

*   Fastmail just want to publish so people can interop with us!

Joris:

*   regarding `@type` think that makes a lot of sense, should mention
    that as the place to do it.

Darrel Miller:

*   looked at mediatype registry, if we fiddle then we may need to
    update that.
*   Bron: maybe do a subtype key.

ACTION: Ken to help, Robert to keep editing.

## jscontact   {#jscontact}

Robert presenting

Done! Complete documents.  
Look forward to thorough reviews! Thanks

Found a couple of nits:

*   discuss and come up with a proposal during WGLC and use same
    mechanism for jscalendar.

Bron:

*   Think we should WGLC.

Mike:

*   CalConnect next week, Tuesday is J\* day.

ACTION: Robert / Mario to publish new version with nits fixed.  
ACTION: Daniel to issue WGLC after that.

## Tasks   {#tasks}

Mike presenting

Hans-Joerg:

*   is this all the things like issue tracking systems.

Mike:

*   Current draft creates a base to build on. Unless extra stuff is
    fundamental, be inclined to push this out without addressing those.
*   Either an extention to both of rolled into jstasks.

H-J:

*   opinion on this -> think from a portability perspective, look at
    what's similar to tasks in Groupware systems.
*   Don't think that what we add there needs to get back to icalendar.
    Don't think all need to be represented in icalendar.

Joris (via chat): Agree

Bron:

*   what next step?

Mike:

*   consider last call!

ACTION: Mike will do a quick readover.  
ACTION: Bron to do last-call on this or next version.

## date and duration stuff   {#date-and-duration-stuff}

*   Not enforced.

Question: errata. Bernard doesn't think an error, was added
deliberately.

Mike:

*   Add to tasks draft?

Bron:

*   Sounds reasonable to me

Daniel:

*   Generally in favour of update, errata are hard to find!

Mike:

*   Inclined to update approach. Happy to add update for this issue in
    TASKS draft.
*   Think that makes more sense.

Ken:

*   Initially stood up to argue for an errata, listening to Mike it
    makes more sense. Just mention in tasks draft.

Bron:

*   Does it make sense to do both?

Francesca:

*   Erratas are for errors or clarifications, however if people have
    implemented it - and created incompatibility, an update is better.

Mike:

*   Not really an ERROR in the spec, just nobody knows why it was done
    and there was no discussion. Since libraries didn't implement
    change, undoing it won't hurt.

Francesca:

*   Errata would be easier, I can just press a button.

Ken:

*   Did an extensive search of mailing list traffic and meeting notes.

## vpoll and series   {#vpoll-and-series}

*   would like to do, no progress.

## itip   {#itip}

Mike:

*   We could do with a better iTIP specification. It could be shorter
    than what it is, and provide better examples.
*   Doesn't make it clear you can AND SHOULD be sending minimised
    components. Doesn't change the workings, just make it more readable.
*   Has relevance to VPOLL, which updates ITIP. That is the biggest
    section.
*   Started looking at what rewritten ITIP might be like. Would also be
    an opportunity to add in some direct reference to JSCALENDAR
    representations and JMAP.

Bron:

*   This sounds good.

Ken:

*   Have discussed with Mike. Agree it needs a rewrite.
*   Not sure how many implementations support counter and
    decline-counter, should be replaced with VPOLL

Mike:

*   Either deprecate or suggest against.

ACTION: Mike will work on a draft, we'll do a call for adoption.

## Milestones were updated   {#milestones-were-updated}