1 / 11

IMAP Quick Reconnect

Alexey Melnikov Dave Cridland Corby Wilson draft-ietf-lemonade-reconnect-client-03. IMAP Quick Reconnect. Changes since the last revision. Fixed description of the synchronization sequence to properly describe how HIGHESTMODSEQ and FETCH MODSEQ are used Record all received FETCH MODSEQ

jendayi
Download Presentation

IMAP Quick Reconnect

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Alexey Melnikov Dave Cridland Corby Wilson draft-ietf-lemonade-reconnect-client-03 IMAP Quick Reconnect

  2. IETF 68 - Prague, Czech Republic Changes since the last revision • Fixed description of the synchronization sequence to properly describe how HIGHESTMODSEQ and FETCH MODSEQ are used • Record all received FETCH MODSEQ • Update client's copy of HIGHESTMODSEQ upon receipt of the tagged OK/NO response, NOT while receiving it • Fixed a couple of typos in the ABNF • It is all Dave's fault :-) • Ready for IETF LC

  3. Chris Newman Alexey Melnikov Stéphane Maes draft-ietf-lemonade-rfc2192bis-04 IMAP URL IETF 68 - Prague, Czech Republic

  4. IETF 68 - Prague, Czech Republic Changes since the last revision (1/2) • Removed “mailbox list” URL type • Was not deployed & was not designed properly • Clarified encoding requirements for relative IMAP URLs (e.g. encoding of “..” and leading “/”) • Removed some advices about connection reuse, which were incorrect • Added examples demonstrating security considerations when resolving URLs • Security Consideration specific to URLAUTH authorized URL

  5. IETF 68 - Prague, Czech Republic Changes since the last revision(2/2) • Removed text about relative URL resolution in MHTML • Updated references

  6. IETF 68 - Prague, Czech Republic Open Issues/ToDo • Some minor editorial issues in ABNF remain • Need WGLC to resolve them

  7. Stéphane Maes Alexey Melnikov Dave Cridland LEMONADE Profile bis IETF 68 - Prague, Czech Republic

  8. IETF 68 - Prague, Czech Republic ESMTP AUTH STARTTLS PIPELINING 8BITMIME CHUNKING BINARYMIME DSN SIZE ENHANCEDSTATUSCODES BURL Profile MUST implement IMAP • STARTTLS • CATENATE • URLAUTH • UIDPLUS • LITERAL+ • CONDSTORE • NAMESPACE • IDLE

  9. IETF 68 - Prague, Czech Republic In-band notifications: NOTIFY (draft-gulbrandsen-imap-notify-03.txt) Bandwidth optimizations COMPRESS=DEFLATE BINARY (including APPEND) Content Transformation Static (CONVERT) Streaming Allow Partial URLs in CATENATE and URLAUTH Phase bis - MUST implement(IMAP) IMAP • All of Profile • Quick Reconnect (QRESYNC) • Search extensions: ESEARCH, WITHIN • Views • CONTEXT (draft-cridland-imap-contexts-00.txt) • Storing views on the server: draft-melnikov-imapext-filters-00.txt (?) • ENABLE, METADATA, LIST-EXTENDED

  10. IETF 68 - Prague, Czech Republic Phase bis - MUST implement ESMTP • All of Profile • QUICKSTART (draft-fanf-smtp-quickstart-00)

  11. IETF 68 - Prague, Czech Republic SIEVE Filters (?) IMAP Sieve How to manage scripts? Phase bis - Optional/undecided Out-band notifications • Format • One or more example binding to a notification protocol

More Related