Minutes IETF106: extra
Email mailstore and eXtensions To Revise or Amend
||Minutes IETF106: extra
IETF106 EXTRA WORKING GROUP - Singapore 2019-11-18, 14:30-15:30
Welcome, Notewell, Bluesheets, Agenda bashing: 5m
* fetch-preview: 10m
* imap4rev2: 20m
* quota: 15m
Milestone review: 5m
Any other business: 5m
* work with Barry to update IMAP4REV2
* consider both https://datatracker.ietf.org/doc/minutes-104-extra/ notes and
this set of minutes to see decisions made (and updated)
* work with Alexey to update IMAP4REV2
* send argument in favour of OBJECTID to the list
* consider ANNOTATION-STORAGE with quota
* update milestones
* update wording of PREVIEW to have client request mediatypes
* upload EAI Sieve draft
= DETAILED NOTES
* Contention: client can't have any idea what algorithm is best, so server
should choose the algorithm
* From Dovecot perspective - have clients who want to be able to fetch image
previews and show them * Particularly valuable on something like a dashboard
where just a couple of emails are showed. * Also valuable where payload is
encrypted and includes a fuzzy image showing enough to be useful to client
"click on this to decrypt and see the actual content".
* Ahh, now I see your use case!
* Sounds like what you want is media types (e.g. Accept) rather than algorithms.
* Do you want RFC5259 CONVERT?
* That doesn't do what we actually need
* Don't want every client asking for a different format - server will produce
ONE preview of text or image type and cache that
* Appears that the consensus of the room is to change the mechanism to be
content types instead of algorithms, but have text/plain be the initial
supported option. * Behaviour will be same as now, just a different format.
* do we need to define a different text/? format for this so we don't block
other use of text/plain? * also: do we need a way to discover what formats a
server supports, since it won't be in capabilities
* clients will just send a query regardless of server support probably, easier
to just leave it unspecified and see what the server will spit back
* Should just have PREVIEW in the capabilities, no need to have a discovery
mechanism, just specify the types you're willing to accept and server will spit
out what it wants.
* This is a major change which will require IESG review again
* But we can do it quickly. Back to the working group, quick WGLC, done.
ACTION: Michael to get new draft done with updated wording
* should we deprecate or just remove FETCH RFC822.*?
* Let's just delete it, likewise "SEARCH NEW". If your client requests
IMAP4REV2 it's opting in to the removals, and should strip them from its code.
* Good - goal is to make all the bits that are in both rev1 and rev2 work the
same, but the compatability path is servers supporting both, not that clients
should be able to keep crappy old stuff once opting up.
* Extended LIST still needs wordsmithing, will meet with Alexey on Friday
morning and work on it
* BODYSTRUCTURE needs more examples, it's a common cause of bugs
* LIST multiple patterns is OUT
* LIST RETURN STATUS is IN
* Binary fetch only leaf nodes has issues with message/global, more research
Long discussion on search - I didn't capture all the names of people who spoke
on this, but the final proposal is:
* SEARCH without modifier works like in rev1 (heuristic)
* SEARCH FUZZY always does fuzzy matching
* add a new SEARCH SUBSTRING modifier which forces the server to use substring
matching. * The server MAY reply "NO" to a SUBSTRING search. * We need to
define an extended response code for that [SUBSTRING-SEARCH-NOT-AVAILABLE] or
whatever. Can do same for FUZZY if that's not supported on a field.
* could also have SEARCH REGEX modifier. Room expressed suitable disgust.
* SEARCHRES is IN
* STATUS DELETED - yes, easy for everyone to add
* Want to do last call before Christmas!
* I'd really like to see OBJECTID included, it's very valuable.
* There's a degenerate algorithm which can be used which doesn't give you all
the benefits, it's:
- MAILBOXID: digest(mboxname,uidvalidity)
- EMAILID: digest(mboxname,uidvalidity,uid)
- THREADID: EMAILID
* This is RFC compliant, but doesn't give any benefits. There's no hard
requirement that same data has same ID after a rename/copy, only that same ID
is never reused for different data.
* OBJECTID is needed for JMAP too
* Not entirely opposed, despite own server not supporting it
* make your case on the mailing list and make it quick!
ACTION: Bron to make case for OBJECTID on the list
ACTION: Alexey and Barry to update doc this week and send for WGLC
* do we want to add ANNOTATION-STORAGE as a separate type?
* is 32 bits enough for each field?
* should we redefine STORAGE in octets instead of koctets?
* feel free to make a case, but these all seem sensible from the numbers we have
* need to make a good case to break backwards compat
* more reviews please!
* plan to address this after imap4rev2 is done
* yeah, I accept all the above - I'll think about ANNOTATION-STORAGE
ACTION: people to review the draft
ACTION: Bron to consider ANNOTATION-STORAGE and whether it makes sense
* imap4rev2 - Dec 2019
* quota - Feb 2020
* charter review - Apr 2020
* eai sieve - May 2020
* will have more time for EAI after quota
* I think Stephan Bosch was going to do EAI Sieve
ACTION: Stephan to propose EAI Sieve document
ACTION: Bron to update milestones
== Other business
Out of time! Take it to the list.