JMAP/CALEXT at IETF122, Bangkok

• Thursday Session II 13:00-14:30 (1:30 hours)
• Room Name: Boromphimarn Ballroom

Intro and notewell: 5 min

Jim presented the note well and really well.

The agenda is very short.

---

JMAP WG

documents: https://datatracker.ietf.org/wg/jmap/documents/
material: https://datatracker.ietf.org/meeting/122/session/jmap

With IESG: 5 min

• webpush-vapid

Published!

• calendars

With the RFC editor.

Stalwart concern on notifications -> issue with Notifications.

Ben: 100% agree, reasons were sound. Invitations are an event on their
own, NOT an event on the calendar yet. User's calendar is his domain to
manage. Requirement comes from real life expectations of people managing
their own paper calendar.

Neil: the email IS the invitation. When you open the email, you can
decide whether to add. With other existing systems, it IS an event on
your calendar.

There was a calendarspam document with M3AAWG that appears not to be
cited.

Neil:

• Not sure I understood how iMIP integrates between email and the
  calendar. Don't see what we should change in the spec from that.

Bron:

• if via iSchedule, it's a separate calendar but still a standard
  event.

ACTION: Neil will look at thread about JMAP Calendars and spam handling.

Work in Progress: 30 min

• filenode

Ken: heckled.

Hans-Joerg:

• Implemented something like JMAP files, re-engineering what Fastmail
  did.
• Would provide a reference implementation.
• Do it with connectors for other systems.
• Will review and provide input.

Bron: thanks, will grab you offline.

Ben:

• Am interested in files as well. Use-case is sharing (same thing you
  do in Microsoft Teams, etc) - want to edit the file together as
  team. send a link to the document.
• Want to add collab with others.
• Spoke with the openCloud.eu people, feedback as "very limited,
  doesn'thave features they need".
• Things like "make a public link, readonly or writeable, or only for
  specific users", or
• "I want to download all the files in this directory", thinking:
  multi-part MIME.

ACTION: Bron to do updated jmap filenode draft, talk to OpenCloud and
Hans Joerg.

• essential
• portability
• rest
• tasks

Hans-Joerg:

• Joris probably won't have time in future to keep working on these,
  which will slow down progress a bit.
• Most describe stuff we're doing already, happy to write them up
  further.
• Might be additional people happy to join as editor.
• I will also work on these myself, but in linear fashion.
• Will pick ONE to bring forward by Madrid.

Hans-Joerg: in weeks after, will write an email about each and see if
anyone wants to help.

• smime-sender-extensions

Bron: had this for many years, no progress. Ask Alexey if it's going
anywhere?

Ken: suggest parkit, can review later.

• archive format!

Was presented in MAILMAINT.

Hans-Joerg: found out may not be in charter for JMAP, which is why it
was presented there.

Ken: has already gone call for adoption in mailmaint.

AOB: 10 min

Neil: Last meeting wanted to do push notification work. Last minute Bron
said would call for adoption.

• haven't done any more work on it yet.

ACTION: Bron to call for adoption of JMAP Push Notification document

Milestone review: 5 min

---

CALEXT WG

Agenda bash - Robert would like to present on jscontact profiles.

Orie:

• tasks -> history shows IANA not-OK.
  • Ken: did expert review on this, looked OK.
  • Don't recall why it went back to Mike.

ACTION: Orie to check with IANA for tasks

• Subscription-upgrade:
  • new version in March. AD Evaluation done. Just need to push
    buttons

ACTION: Orie to check subscription-upgrade status.

Orie: feel free to ping me; I don't mind reminders.

documents: https://datatracker.ietf.org/wg/calext/documents/
material: https://datatracker.ietf.org/meeting/122/session/jmap

JSCalendar: Converting from and to iCalendar

• draft-ietf-calext-jscalendar-icalendar-10

Robert presenting.

See Mike isn't here, not sure where his implementationis at.

Hans-Joerg: we have an implementation, may need to check if it's up to
date. Have sent link in the chat.

ACTION: finish implementation and interop testing for
jscalendar-icalendar.

iTip using PARTICIPANT only:

• draft-ietf-calext-itip-participants-00

Ken: think it's going to need interop testing.

VPOLL: Consensus Scheduling Component for iCalendar:

• draft-ietf-calext-vpoll-07

Ken:

• Mike has re-written his implementation to use participants and it's
  functional.
• I updated libical to current spec. Don't know where our
  implementation is up to.

ACTION: Ken and Mike to do interop testing for vpoll

Support for Series in iCalendar:

• draft-ietf-calext-icalendar-series-03

AOB

jscontact-profiles:

Robert presenting

Ken: in favour, good to provide a framework for people.

Hans-Joerg: good to see interest. Idea of profiles makes sense.

• Questions: do you plan on formalising the description of optional
  properties, so library implementors could integrate it?
• Robert: yes, headers in the table would be elements in the registry.
  So you could define it; should be easy to process when you download
  the registry as a CSV file.
• Maybe IANA support XML, but otherwise they definitely do CSV and it
  works fine.
• Would not want to use sophisticated schema, people should be able to
  use IANA registries.
• For extensible properties (not in core):
  • profile would be frozen to just these properties unless profile
    is updated.
  • Robert: let me clarify, but in context of this draft, conforms
    to the profile only if it includes elements in the profile.
  • Doesn't conform does NOT mean invalid.
  • Do not encode profile name in the card.

Hans-Joerg: proposed in Calext, not JMAP?

Bron: is in scope for Calext!

Andy (no hat):

• tried to implement jscontact in RDAP, and walked away
• RDAP does need a profile. Answered one of my questions; once you set
  a profile, these things don't change.
• How does this work in IANA?

• Robert: would assign a name; and you would get this table.

  • We made an effort with jscontact to make it so you can build a
    validator from IANA.
  • Wanted to make sure the same for profiles.

• Really want to make profile not support patch objects, far more
  complication than anyone is willing to do.

• RDAP clients are extremely simple - right now we use JCARD.
  Jscontact would be better, but when you get a jscontact you need to
  json pointer stuff.
• Robert: could have a boolean "allows patch objects"; only used for
  localisations now.

Hans-Joerg:

• Just what Andy said made me think this might have a relation to the
  "essential profile" document in JMAP. We wouldn't want to implement
  patch for our case too. Might think about syncing both approaches;
  aim is to help other communities to make use of JMAP data structures
  and functionality.
• Robert: yes, was also thinking about the work you're doing.

Pete:

• Apparently, I'm still the chair of VCARD! Got an email from W3C
  about RDF format for VCARD.
• Pointed them to jscontact/jcard.
• Would like to punt this.

Orie:

• I'm happy to take your email.

ACTION: Bron to issue call for adoption for jscontact-profiles

AOOB

Hans-Joerg:

• archive format => there's IMAP "special folders". For non-email
  archive format, there's no such thing.

• e.g. "personal", "default", etc.

  • Name might be different in different systems, etc.

• In JMAP there are "role(s)"

Bron: a live property on the DAV collections?

Or define it on the archive format only?

Ken: apart from inbox, outbox, default? What do you want?

Hans-Joerg: e.g. photos, videos, etc for files - personal or work.

AOOOOOB

Robert: about page, suggests jscontact is still a draft - refers to JMAP
WG's version.

Should we rename the working group to "calendar and contact extensions?"

Orie:

• Text you're referring to is top of charter text. To change that, we
  have to change the charter!
• With AD hat on, gather a bunch of things.

ACTION: Bron to work with Orie about making CALEXT about page better.

Ben:

• while on the topic of scope - what group is the right place to
  standardise sending links?
• Bron - it would just be an API call.

Ken:

• For webdav, guess you define a property, and the client will get it,
  and the server might generate it on the fly.

Lisa:

• Capability URL is probably it. Webdav property implies some
  persistence.
• Don't see why it would be limited to webdav.
• Bron: it would be "this path on the server"

Hans-Joerg:

• important portability issue. This is something you can't easily
  port! But is a blocker for people to switch providers, because it's
  a reference that's very much bound to a particular provider.

Lisa:

• since webdav resources are just HTTP resources; but webdav
  collections may be specific.
• Sounds like useful work! Can't remember it being seriously
  discussed.
• Think we should take if offline, but happy to be involved.

Ken:

• was going to suggest this goes to httpbis or httpapi.

Lisa:

• W3C published practices for capability URLs.

NEXT STEPS: discuss