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:
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.
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:
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:
Mike:
ACTION: Mike will do a quick readover.
ACTION: Bron to do last-call on this or next version.
date and duration stuff
Question: errata. Bernard doesn't think an error, was added
deliberately.
Mike:
Bron:
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:
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