EXTRA session minutes - IETF104 Prague - Monday Mar-25-2019 13:50
===

Welcome Barry as new area director for the EXTRA working group.

CHAT OVER IMAP:
* A chat client, but using email underneath
* proposed "submission token" spec can be used for any email flow,
  not just COI
* can always fall back to "slow path", this is an upgrade to faster
  mail flow where there's an existing relationship/conversation
  happening between the parties.
* Dovecot / OpenExchange have been playing with this for a while
  internally - looking for input from this group.

Discussion of details:
* different trust levels: temp/perm - does that make sense?  Or
  just always refresh?
* does the token come with a submission server name?  Not right now,
  use MX or SRV.  Maybe token should include submisison server hostname.
* discussion of using token to say "prioritise this message" but keep
  the flow in band: problem, if everything is special, nothing is special,
  and every hop needs to honour this.  Still not as fast as direct injection.
* should this use HTTP POST rather than SMTP at all?  Pros and cons.
* lots of baggage comes with using email as the transport, but maybe that
  frame cost is OK so long as latency is low.
* discussion of "using offsite mail filtering" as a common cause of a latency
  path that this could bypass.
* standards-track "delivery-by", if not delivered by a certain time, drop it.
  Kind of the opposite of what we want here though.

Dicussion of barriers to adoption:
* many sites won't want to allow direct SMTP injection that bypasses their
  corporate firewall.  Though if you're running a Jabber server, that does
  much the same thing!
* Pro of SMTP vs HTTP post, just connect to a different server with different
  creds but inject same existing message via same SMTP protocol - less special
  case for client.

Discussions of where the work could happen:
* During the IETF fax working group there was a proposed SMTP immediate
  delivery mechanism.
* Way back in 821 there was an SMTP command for exactly this mechanism
* It couldn't happen in EXTRA - this would have to be an SMTP working
  group.


RECHARTER:
* This group was originally chartered without SMTP to avoid distraction and
  due to pushback about starting that work.
* If we did SMTP, we'd also redo message format (RFC532[12] and MIME) and
  move them to internet standards.
* ACTION: Bron to write an updated charter for EXTRA, continuing with our
  existing maintenance work.
* ACTION: Alexey/Barry to write a charter for an SMTP/MIME working group.

QUOTA:
* Last time we met there was interest in a quota extension
* Alexey and Dave Cridland already have an old draft
* Call for co-author, Michael is interested in co-editing
* Discussion of making setquota optional.
* Discussion of "storage used" vs RFC822 sizes.  Decided to mirror the
  language in RFC8438 STATUS=SIZE:
    >  [...] it MUST be equal to or greater
    >  than the sum of the values of the RFC822.SIZE FETCH message data
    >  item [IMAP4rev1] of all messages in the mailbox.
* ACTION: Bron to issue call for adoption