CALEXT Agenda - IETF115 London

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

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

Bron did the intro

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

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

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

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

• 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

• would like to do, no progress.

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