Why every email client with a calendar should ship METHOD:COUNTER

The iCalendar standard has had a clean way to propose a new meeting time since 1998. It is called METHOD:COUNTER, it lives in RFC 5546, and almost no major email client uses it correctly. The cost of that gap is the reason "let me check my calendar and get back to you" is the default reply to every meeting invite. Counter-proposing should be a tap; it is a thread.

What METHOD:COUNTER actually does

The protocol is straightforward. The organizer sends a METHOD:REQUEST invite with a proposed DTSTART. An attendee who wants a different time replies with a METHOD:COUNTER message containing the same UID, a bumped SEQUENCE, and their proposed DTSTART. The organizer's client receives that, surfaces "Alice proposed 4 PM instead of 3 PM. Accept?", and on accept emits a new METHOD:REQUEST to all attendees with the updated time.

The whole exchange should be three taps. Tap to counter, tap to accept, tap to confirm. The attendees who were not in the loop get their calendars updated automatically because the new REQUEST has the same UID and a higher SEQUENCE than what is already on their machines.

That is not what happens.

What every major client actually does

Apple Mail and Calendar. Will send a counter-propose, but the affordance is hidden two menus deep on macOS and is missing entirely from the iOS invitation UI as of 2026. When a counter-propose arrives, Calendar shows a banner that organizers consistently miss because it is styled identically to a regular invite update.

Outlook (desktop and web). Renders the COUNTER as a proposal banner, but on accept it does not always re-emit a REQUEST to the full attendee list, so other attendees' calendars silently drift from the organizer's. We have caught this in the wild on both Outlook for Mac and outlook.com.

Mozilla Thunderbird with Lightning. Best-in-class support, which tells you everything about the state of the world.

Gmail. Here is where the eight-year tax is actually paid. Gmail does not parse METHOD:COUNTER at all. If you forward a Google Calendar invite to Gmail and reply "how about 4 PM," Gmail pastes the new time as plaintext in the thread. The organizer's client never sees a structured counter-propose. If the organizer is also on Gmail, they have to read the reply, understand the new time, open the event, edit the time, and resend to all attendees. That is five steps that should have been one.

The downstream cost

This is the part that does not get measured but matters enormously. Because counter-proposing is friction-y across the dominant clients, the social default has shifted to "let me check my calendar and get back to you." That reply mode exists because the alternative — proposing a specific new time on first reply — is harder than it should be. The protocol designed the affordance correctly; the clients eroded it.

You can see the cost on any team that schedules meetings across organizations. A two-person meeting that should have settled in one exchange settles in three. Multiply by every cross-org meeting in a quarter and you have lost a workweek per person to a problem the spec solved 28 years ago.

What it takes to ship it correctly

Counter-propose is not a hard feature to implement. The required surface area is small:

1. Parse METHOD:COUNTER on inbound: pull UID, SEQUENCE, the new DTSTART, and the proposing ATTENDEE.
2. Match it to an existing event in the user's calendar by UID.
3. Surface a first-class banner on that event: "Alice proposed Thu 4 PM (was 3 PM) — Accept, Decline, or Counter again."
4. On accept, generate a new METHOD:REQUEST with SEQUENCE bumped, DTSTART updated, and send to every attendee on the original ATTENDEE list.
5. On decline, send a METHOD:DECLINECOUNTER back to the proposer only.

Total implementation time on Emcognito was under a week. The protocol does the heavy lifting.

Why this is in scope for email-first products

Calendar lives in email. Invites arrive as messages. Replies are messages. RSVPs are messages. An email client that ships a calendar but does not handle the structured RSVP messages the spec defined is shipping a calendar with a hole in the middle of it. That includes counter-propose, decline-counter, and a few other methods that get the same neglect (REFRESH is the other big one).

The framing matters more when you operate multiple brands. A multi-business operator is in dozens of cross-org meetings a week, each one with a different identity, and the counter-propose loop is the single most common multi-step interaction. Making it one-tap pays back constantly.

The case for Gmail specifically

Gmail is the inflection point because Gmail is the client. If Gmail parsed METHOD:COUNTER correctly and surfaced it as a first-class banner, the social default for cross-org scheduling would shift inside a year. The protocol is there, the data is on the wire, the affordance is one engineering quarter of work.

Until that ships, every other client that handles COUNTER well still loses because Gmail is on the other end of half the meetings. The right move is for clients to handle COUNTER inbound from Gmail's plaintext fallback as a best-effort parse, surface it as a structured proposal anyway, and emit a clean REQUEST on accept. That is what Emcognito does. It is a workaround for a problem that should not exist.

What we did about it

Emcognito parses inbound COUNTER, surfaces it as a first-class banner on the event, and emits a SEQUENCE-bumped REQUEST to all attendees on accept. We also parse the Gmail-style plaintext fallback ("how about 4 PM Thursday") with a narrowly-scoped natural-language pass against the original event's time zone and proposed start, and we surface that as a proposed counter for the user to confirm or reject. We do not auto-accept; the user is always the decision-maker. The full RSVP behavior is documented at /docs/calendar-rsvp.

FAQ

What does METHOD:COUNTER do in an iCalendar invite?

METHOD:COUNTER is the iCalendar method an attendee uses to propose a different meeting time than the one the organizer requested. It reuses the original event's UID and bumps the SEQUENCE so the organizer's client can match the counter-proposal to the original invite and surface an accept/decline affordance.

Does Gmail support counter-propose for calendar invites?

Gmail does not parse METHOD:COUNTER as a structured proposal. A counter-proposed time arrives as plaintext in a thread reply, which means the organizer has to read the message, edit the event manually, and resend the invite to all attendees rather than accepting the proposal with one tap.

Why is counter-proposing a meeting time so awkward in 2026?

Because the major email and calendar clients render METHOD:COUNTER inconsistently. Apple Calendar buries the affordance, Outlook can drop attendees from the resend, and Gmail does not implement it at all. The protocol has supported clean counter-proposals since 1998; the clients have not caught up.

How do I propose a new time for a meeting without starting a thread?

Use a client that emits METHOD:COUNTER on the calendar protocol layer, such as Thunderbird with Lightning or Emcognito WebMail. On the receiving side, the organizer sees a structured "Alice proposed 4 PM" prompt rather than a plaintext suggestion, and accepting it automatically updates every attendee's calendar.

Related reading. Calendly vs. Emcognito booking links: the per-seat math when you run multiple brands and Subscribe to Google Calendar without giving us OAuth scopes.

See /calendar for the full calendar feature set.