Skip to main content

Minutes IETF103: extra
minutes-103-extra-00

Meeting Minutes Email mailstore and eXtensions To Revise or Amend (extra) WG
Title Minutes IETF103: extra
State Active
Other versions plain text
Last updated 2018-11-08

minutes-103-extra-00
EXTRA MINUTES - IETF103 BANGKOK - 8 NOV 2018

Existing docs
---

savedate:
* comments needed in response to IESG tracker
* don't believe anything else is required

ACTION: Alexey will progress

sieve-fcc:
* ABNF suggests that tagged params have other parameters still,
  wordsmithing required
* Alexey has suggested a change

ACTION: Bron to talk with Ken about fixing wording

sieve-special-use:
* ready to progress

ACTION: Jiankang to submit for publication

imap4rev2:
* needs more examples, particularly around BODYSTRUCTURE
* also clearer wording for these difficult parts
* needs examples for bodypart.MIME and bodypart.HEADER
* suggestion to look at unofficial IMAP wiki for useful words
* Q: is it legit to require only UTF8?  Not for search, which needs
  to be able to match charset of data, but everything else is UTF8
  only in imap4rev2
* open issues - all to be asked on the mailing list!

ACTION: Bron to start 1 thread per open issue on the list

ACTION: Bron to email other IMAP-related lists asking for input from
        client and server implementations about these issues

TIMELINE: expect to be done by March (submit for publication pre-Prague)

preview:
* debate over 200 vs 255
* good to align with JMAP so servers can store one value
* other than this issue, take to working group last call

ACTION: Bron to email list with 200 vs 255 question.

64bit:
* 53 bits is plenty
* Nobody is clamouring for this or needs it
* The couple of places (STATUS=SIZE and quota) will handle 64 bit separately

ACTION: leave it dead


Group next steps:
---

* General support for keeping a group around to deal with email stuff,
  so we will keep operating while there's work trickling in
* Document for sieve and EAI -> Stephan will have a go at it
* QUOTA-BIS - Alexey has a start - happy to give to another editor
* SMTP-related work:
  - options - recharter this group or spin up a new one
  - replace RFC532[12] with new version which include errata an
    replace 82[12] as "INTERNET STANDARD" docs.
  - MIME specs as well?
  - new WG vs recharter should go to the list.
  - in theory only a couple of months' work, but could easily go into
    the weeds and fail as the last couple of attempts have.

ACTION: Bron to email list regarding sieve-EAI proposal

ACTION: Bron to email list with request for author for QUOTA-BIS

ACTION: Bron to email list regarding recharter vs new SMTP group

Discussion of "scaring off new people"
---

* CLIENTID proposal at Montreal led to potential contributors
  not engaging.
* Were we too abrasive and dismissive?  Hard to be sure.  There
  was broad agreement in the group that the work itself was
  worthwhile, but this group wasn't at the right level of the
  stack.
* Followup discussion was unproductive, felt like talking past
  each other.
* Bron: could have set expectations better - presentation felt
  more like a sales pitch than a technical presentation.
* IETF level - would help to have more orientation, like "shower
  before you get in the pool" - so people know what to expect.
* Newcomer vs "Tourist" - expectation that there's lots of work
  to do and that someone coming to the IETF has to contribute as
  well as get what they want - it's a collaborative process, not
  a rubber stamp.
* Pete: would help if we volunteer to guide people, up-front comms.
  - only helps if they're willing to learn about us though!
* In a perfect world we may have been able to salvage something
  from the Montreal experience, but generally we're happy that
  we're a fairly welcoming group.  We'll be thoughtful about how
  we handle new people going forward, and keep track of what's going
  on in the rest of the IETF.

ACTION: nothing concrete, keep being thoughtful

BIMI
---

BIMI is organisational logo per message based on email authentication
complience.

Should we talk about BIMI?
* more likely it belongs in DMARC than here.
* would be good to discuss the work within the IETF and make sure
  we're handling security considerations wisely.
* Governments are pushing DMARC, which is useful in their sphere of
  influence.  BIMI helps push adoption by commercial interests.

ACTION: no action taken, will keep talking

Should we merge with other email related groups?
---

* UTA is working on TLS1.3 recommendations and deprecating TLS1.1, so not
  really.
* suggestion to try to put EXTRA and JMAP together on the schedule
  for future meetings, since much the same people come to both.

ACTION: Bron to request co-location in Prague requests for EXTRA and JMAP.