Tuesday 2024-11-05 16:30-17:30 GMT
(pre-meeting discussion)
Daniel: could we add an ICS feed to the datatracker for the parts of the
agenda that you're interested in?
Bron: might be a fun datatracker hacking session task
Both complete.
Mike: Robert raised issue on percent complete; will re-submit the draft.
Ken took a look through (nods)
Both good to go.
Mike will check in next couple of days that all issues are dealt with.
ACTION: Mike will submit new docs for tasks and upgrade in the next
couple of weeks, Bron will do a new WGLC since it has been so long.
Mike: no real change to iTip, just the mapping is different. Required a
bunch of properties. JSCalendar also uses participants.
No attempt to deal with multiple owners for an entity; though it has
been raised multiple times. Will have to do as an extension. Need to
extend ATTENDEE to add additional properties.
Existing entities MUST continue to use ORGANIZER/ATTENDEE. Looked at
tighting up eventpub. Can deal with on the list. How do you know which
properties? Add PARTICIPANT as well as ATTENDEE? Probem with keeping in
sync. Might want to tighten up the statement. Participant must be a
complete statement of attendee if you're doing that, but not a change to
iTip.
Want to push this ahead of the other two, so they can reference this
draft.
Working in Bedework and ical4j. Mostly this is removing the old VPOLL
work and redoing it properly. Not that hard to implement scheduling with
participants instead. Occasionaly push stuff back; can already be done
in java.
Bron: is it ready for adoption?
Robert: very much in favour of adopting this, will also be useful for
the JSCalendar work we're doing.
Comment from Mike on how to keep data in sync -> have discussed this
offlist a bit. Don't have a good answer for that; should be part of this
RFC.
Will also implement in the Cyrus implementation, so will have another
datapoint on how to deal with potential data out of sync.
Daniel: can we find a good answer by end of year, or should we plan
further ahead?
Mike: don't think it needs to take a long time. Really a guide for how
to implement it if you want to schedule VPOLL. Doesn't make real changes
to iTip.
Mike: no significant issues, should be able to do by end of year.
ACTION: Bron will do a call for adoption on list for itip-participant.
Robert:
not persuing jscalendarbis any more.
experimental statement: question == when would experiment be considered
successful? When jscalendar data is successfully processed.
Another experiment: 2 different implementations, produce same output
from same input.
Think we're doing OK, but not meeting charter yet. Participant component
in iCalendar; only covering half the properties that are explicitly
mentioned in iCalendar ABNF.
It's fuzzy in JSCalendar if the owner is the scheduling organizer, so
need to make that explicit.
Propose SHOULD for charter!
Next steps -> finish conversion, finish implementation, start
experiment.
Last call for IETF122?
Bron: want to ask about "experimental RFC" or "ask for experience?"
Joris: want to reiterate; this document defines new properties for
Events, etc. Should only include properties from conversion, not
additional things?
Robert: yes, that's the scope.
Orie (AD):
Happy to have conversation around changes you want to discuss regarding
the charter. Joris answered part of the question - in these tables
showing "50% in worst case compliance" - data model in two formats, 50%
loss in data modeling parameters, but charter says should be 1-1
mapping.
Saw interest in relaxing charter constraint.
Orie: Relaxing would just make less reliability?
Robert: while working on this, do not see this as a concern. Where it's
critical to preserve information, will add it. For the rest - it's
really only relevant once services want to serve calendar data over
CalDAV in both formats (using accept header) - do not see it happening
any time soon.
See JSCalendar being used in JMAP for calendars, interaction will mostly
be iTip which is already quite restricted.
Orie: point about experimental documents; I'm a fan. Want to describe
what success looks like. Want to see what criteria people are looking
for. Thinking up-front in document is good. Need to check registry,
don't want to burn points in the registry.
Is anything on the list? No, just starting here.
Orie: want to see this on the list.
Reason to publish experimental RFC - want implementations. Protects you
from having implementers have to do that.
Robert: happy for either, long-living draft or published RFC number.
Bron: suggest less commonly used things are in there.
Robert: depends on how the working group interprets "Robust"
Mike: when I did the mapping - when I tried to include jscalendar, made
for a messy document. Maybe do a separate document for the mapping? Also
think may be worth re-chartering a bit. Should be concentrating on the
core specifications. Until we get iTip working with JSCalendar, it's not
going to have much of an adoption, and that's the core.
Am a bit wary about experimental status - how do we get people to do it,
should preserve appearance of "will be a standard spec"
Robert: would want to see at least 2 robust impementations that can
interoperate.
Mike: have a nearly robust implementation! For future documents, it's
progressively easier.
Ben: quick comment on the properties - what makes people miss a meeting
is start time, location, summary, description (including RRules and
Timezone). Specific question -> discussion of HTML in events. Experience
that backwards compatibility from description and htmlDescription
(styled description) is a problem. If they're not in sync, change of
description doesn't get seen. Needs to be some mechanism to detect that
or make sure clients that are not aware invalidate that. Thunderbird
uses a parameter on the property so if you rewrite the description it's
more obvious that the parameter gets dropped.
Robert: core calendaring data; is covered completely in both iCalendar
and jscalendar, on concerns. In JSCalendar this isn't an issue, there's
only one description. Issue becomes creating a plain-text rendering as
well. Question is whether client will preserve DERIVED=TRUE when
changing the value.
Think we should discuss this in the WG.
Mike; that spec was drawn up with Google cooperation. Like a lot of
things, a matter of trying to persuade vendors to implement.
Neil: want to say mostly things that don't map are mostly because
they're not important. Most of the stuff we don't do are things that
people ignore. Mostly want to evolve to a better.
Daniel: we're robust enough, don't think we need to re-charter for that.
Want to avoid rechartering, will distract the WG with process work
instead of the core work we need.
Regarding standard vs experimental - depends on calendaring community.
From operators; nobody will take time to implement it. Content doesn't
change. Right way is how people will interpret. For me, don't care - but
cautious. Experimental is a reason why people wait for standard. And
even standard documents get re-written. Standard is always proposed
standard anyway until 20 years experience.
Robert: point of experimental, might incentivise people to do it, but if
that's not how people read then no point.
Hans-Joerg: on Mike's comment - useful beyond just iTip. We use it to
convert legacy data. Needs to be an upgrade path.
To Orie's comment, OK for it not to be 100%. Most data not in here is
very rare properties, and customers are generally happy. Regarding
experimental, agree with Daniel - mappings now are stable. Key things
work fine now. Also happy to implement draft.
Given feedback; not experiment success criteria.
Alexey: in HTTP working groups, they had implementation milestones. Said
"please implement". Robert will look.
ACTION: Robert will take discussion to the list about setting a version
as "please implement" and encouraging interop testing
Were updated, but we didn't have time for AOB.