Minutes IETF104: extra
minutes-104-extra-01

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




EXTRA session minutes - IETF104 Prague - Tuesday Mar-26-2019 09:00
===

IMAP4rev2:
* BINARY - agreed that it should be leaf nodes only
* SEARCHRES - include
* MUST sent BYE - much discussion
  - e.g. TLS issues, can't even get a BYE down the wire.
  - conclusion: remove the MUST
* Mailbox naming: Barry will look over the whole section
  - landmines for V1/V2 implementations
  - Chris has implemented, subtle issues around bare '&'.
  - Server needs to track if client has enabled imap4rev2
    or smtputf8.
* AUTHENTICATE
  - take out DIGEST-MD5 and suggest SCRAM-SHA-256.
  - But don't make it mandatory.
  - Suspect pushback from SEC ADs about not making it mandatory.
* LIST reference argument
  - leave it as it is
  - explain why it's there and don't use it unless you have a strong use case
  - tell clients to use ""
* LSUB - remove
* Drop CHECK
* SEARCH:
  - know at least 4 servers which implement it differently, nobody seems to mind
  - document should advise substring as a sensible default if you don't have an
    engine that does something else.
  - Barry will look at this.
* Auto \Seen
  - don't change anything, but advise use of .PEEK
* UID EXPUNGE will be fixed
* RFC822 vs BODY[]
  - properly DEPRECATE.  Advise use of other forms, but don't remove in this spec.
* CAPABILITY
  - mention it can be sent in auth responses
* NAMESPACE response -> add some text
* Make sure SEARCH TEXT and SEARCH BODY differences are clarified

ACTIONS:
* Barry to look at Mailbox Naming
* Barry to look at language for SEARCH
* Alexey to look at capability and namespace text

* NEXT STEPS: hope WGLC soon

Milestones:
* IMAP4rev2 -> June 2019