CALEXT at IETF114

Wednesday July 28, 2022 13:30-14:30
Room: Independence C
MeetEcho

Agenda

Intro and notewell 5m

Existing Work

• jscalendar and related 10m (Robert/Mike)
• jscontact and related 15m (Robert/Mario)
• icalendar tasks 10m (Mike)
• other icalendar extensions 10m (Mike/Ken)

New Work

• hopefully nothing right now! We have to get some stuff finished

Milestones 5m

AOB 5m

MINUTES

jscontact

Robert: jscontact extensions is likely not complete yet - but will
publish all three together, because it doesn't make sense to separate
them

Some of the new properties will be added with the same semantics between
vcard and icalendar

Labels -> mostly added because of what Apple did for their addressbook.

Labels in Apple? Does anybody know how it's being used? Hans-Joerg can
look it up, doesn't know off the top of his head.

Robert: question, is the label useful for every object type?
Independently, do we want something like what Apple is doing with
X-ABLabel? If no opinion in the room, will keep working.

Robert: for interoperability, we should understand what X-ABLabel is
used for - so we should find a way to map it?

Joris: the label property should at least be as powerful as the Apple
X-ABLabel property, but it doesn't necessarily need to be more powerful.
If we can map between the two, that's fine. If we can't map the full
label property of JSContact back to the Apple format -> from old to new
needs to be 100%, the other way not so much.

Robert: the charter requires us to do a full mapping. There are pros and
cons of using the same X-ABlabel, otherwise we should clarify that it's
for short identifiers only.

property groups:

Don't know of a use-case where property groups are used. If anybody
knows of a usecase, please let us know!

Hans-Joerg: no particular strong opinion right now. Only system I've
ever seen using these properties is Apple. Might need to look into
whether the case for Apple makes sense. Will have a look.

Robert: definitely want to preserve them, but don't know if we need to
make them first-class.

not mapped things

Robert thinks we should allow time on birthdays, some people know their
exact time of birth.

jscalendar

Both will share some definitions between icalendar and vcard. Want the
mechanisms to be exactly the same for both formats.

reply-to property

Don't have ways to map multiple URIs to icalendar.

Discussion of options:

Neil: have thought about this quite a bit, still think the current
version is the best option, although... (bad echo issues)

• Should rename other to something else to be more explicit. Could
  merge them into a single item, but could use something else. Would
  be much cleaner for sites that do different things. The reason to do
  it as a sub-object is namespacing, so you can add support for a new
  scheduling thing without clients needing to know about it.
• Spec can say "can know which identity is you, by looking for the
  matching property". Server can just tell the client "put this object
  as the sendTo".
• From icalendar to jscalendar is straightforward. Goes to imip,
  otherwise to the other
• From jscalendar back, take the imip or other if it's not there. If
  we want to store them in icalendar we'll need a new property but
  that's OK.

Mike: main thing here is separating out the organizer from the reply-to
address. We can extend iTip to add a REPLY-TO.

• Not sure we should anticipate future things. Would be nice to
  standardise a way to respond to an invitation via the web. The
  current HTML body approach works, but would be nice to standardise.
  Can add it later.
• Would like to see us get iTIP working, not try to anticipate some
  future method we don't have.

Bron: suggest that we keep the object but only define a single item and
allow anything in it (direct icalendar map)

Neil: by saying it has to be a URI means that the client can match
exactly.

Robert: given the charter, scheduling between icalendar and jscalendar
needs to be the same, so heuristics are bad, needs to be totally
accurate and hard to get wrong.

Neil: if I have an event in my calendar, how do I know which of the
participants is "ME"? Right now, it's knowing if the address matches my
own.

Robert: trying to address in RFC7986 -> the new "EMAIL" parameter.
Identifies them in their addressbook, but not necessarily the address
you send the IMIP to.

Robert: don't think we've progressed from lack of consensus on the
mailing list.

Neil: will write up more on the mailing list.

Rik: sounds like part of the problem is conflation of identity and reply
mechanism, and right now we have a single value (attendee) and that's
their reply to. Can always reply with the organiser. Say that the field
there is their ITIP address.

• To get rid of the heuristic, replace the address with an array.

Neil: is the difference just that it's an array?

Robert: but we can't do that with iTIP right now.

Rik: will write up for the list.

Ken: wanted to thumbs up what Bron/Mike said

• need to preserve the identity of the attendee or the organizer.
• no distinction between itip/imip.
• think we should allow this to be extensible, but not jam anything
  else in.
• agnostic on object or array. Robert agrees.

unknown properties

ONLY allow vendor extensions, no name clashes.

Mike: doesn't deal with implementations getting out of sync. Rejecting
perfectly valid object.

Bron: am not a fan of all the / characters in the URIs and how that will
work with our patch syntax.

Robert: any reason not to do option2 (only non-vendor extended
properties are the ones in jscalendar-bis)

Ken: suggest that if there are vendor specific properties, can they
define their own URN? Avoid slashes.

Robert: for option1, there's the unresolved question of how to deal with
name squatting.

tasks

suggest dropping the constraint - ical4j doesn't apply it. Allow
duration without dtstart.

Ken: agree with Mike's assessment. Would libraries choke? libical
doesn't enforce dtstart with duration.

That being said, not sure if we can rewrite. Not sure if ERRATA or
UPDATE?

Ken: looked at mailing list and "things changed", no evidence that it
was intentional, probably a mistake.

Joris: might also affect mapping between icalendar and jscalendar.

Mike: that's where it came up!