1 / 25

Lemonade Interop event in Munich

Lemonade Interop event in Munich. Overview. When compared to the previous interop event in London 2 new client implementations + 1 more planned 2 new full (IMAP & SMTP) implementations of Lemonade Profile (RFC 4550) 2 new IMAP server implementations

ownah
Download Presentation

Lemonade Interop event in Munich

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. IETF 70 - Vancouver, Canada Lemonade Interop event in Munich

  2. IETF 70 - Vancouver, Canada Overview • When compared to the previous interop event in London • 2 new client implementations + 1 more planned • 2 new full (IMAP & SMTP) implementations of Lemonade Profile (RFC 4550) • 2 new IMAP server implementations • Some bugs found, but they were relatively minor • Interoperability improved since the London interop

  3. IETF 70 - Vancouver, Canada Surprises • All clients and 5 out of 6 servers implemented CONDSTORE; 3 servers implemented QRESYNC • All clients and [other] 5 servers implemented BINARY FETCH • 5 servers implemented LIST-EXTENDED • 5 servers implemented ESEARCH • 5 servers implemented SASL-IR • Everybody implemented IDLE • WITHIN supported by 5 servers, but only by 1 client

  4. IETF 70 - Vancouver, Canada Other results • Things that were found broken during the interop in London were fixed since • NOTIFY and CONVERT were found to be important by both client and server implementations • Nice talk about other functionality needed by clients • Extended error handling in URLFETCH/FETCH • Returning STATUS information in LIST • Ability to store search criteria on the server • Ways to send application configuration to mobile devices

  5. IETF 70 - Vancouver, Canada Thank you! • Thank you to Arnt Gulbrandsen & Oryx for hosting the event

  6. IETF 70 - Vancouver, Canada Extended URLFETCH for binary and converted parts Dave Cridland draft-cridland-urlfetch-binary-00.txt

  7. IETF 70 - Vancouver, Canada Overview • draft-cridland-urlfetch-binary-00.txt • Adds ability to fetch bodypart as binary, or just request its bodystructure • C: a002 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlauth=submit+fred:internal:91354a473744909de610943775f92038" BINARY) • S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlauth=submit+fred:internal:91354a473744909de610943775f92038" ~{28} • S: Si vis pacem, para bellum. • S: • S: a002 OK URLFETCH completed

  8. Arnt Gulbrandsen draft-gulbrandsen-imap-enable-03.txt IMAP ENABLE IETF 70 - Vancouver, Canada

  9. IETF 70 - Vancouver, Canada Open issues/ToDo(1 of 2) • In which states the ENABLE command should be allowed: all, only after authentication, ... • Not a big deal either way, but Alexey prefers in all states • Do we want to allow enableable extensions in non-authenticated state? • Handling of ENABLE for unrecognised extensions: send error or ignore • Mailing list consensus to ignore? • Handling of ENABLE for extensions that should not be enablable (e.g. IDLE): send error or ignore • Mailing list consensus to ignore?

  10. IETF 70 - Vancouver, Canada Open issues/ToDo(2 of 2) • How the client can learn if a particular extension was enabled or not? • Mailing list consensus to add a new “ENABLED” response • Does ENABLE affect CAPABILITY response/response code? • Should not change how CAPABILITY response is processed in clients, i.e. can change after TLS or authentication, but otherwise is persistent • Clarify that once enabled an extension can't be disabled • Clarify that ENABLE can be issued multiple times and is additive

  11. Alexey Melnikov Peter Coates draft-ietf-lemonade-convert-12.txt IMAP CONVERT IETF 70 - Vancouver, Canada

  12. IETF 70 - Vancouver, Canada Open issues(1 of 2) • For image types parameters are likely to be by destination type only. So it makes some sense to be able to specify • /convert/image/jpeg/image/gif/params • /convert/image/@/image/gif/params • /convert/@/@/image/gif/params Any objections? • Add extended error handling from Peter's draft? • Extend CONVERTERROR TEMPFAIL to return retry period? • Replace CONVERTERROR with ERROR?

  13. IETF 70 - Vancouver, Canada Open issues(2 of 2) • Dependency on IMAP METADATA • METADATA might be hard to implement, but it is already implemented by 2 servers • If METADATA is preserved as a dependency: do we need new client friendly command for retrieving list of conversion parameters and MIME types? • Add ability to convert headers (e.g. RFC 2047 encoding removal)? • Need a separate document documenting conversion parameters (such as device ID, etc.)

  14. Chris Newman Arnt Gulbrandsen Alexey Melnikov draft-ietf-imapext-i18n-13.txt IMAP Internationalization IETF 70 - Vancouver, Canada

  15. IETF 70 - Vancouver, Canada Open issues (1) • (Mark) UNICASEMAP and COMPARATOR capabilities • Should they be changed to I18NLEVEL=1 and I18NLEVEL=2 respectively? • Mostly syntactic change, but also might affect which comparator is selected by the server as the default • UTF-8 mailbox names • Should this feature be defined in this document, or should this be done in the EAI WG? • If in EAI, should this be Standard Track or Experimental extension? • Internationalization of IMAP keywords

  16. IETF 70 - Vancouver, Canada Open issues (2) • Internationalized usernames/passwords • Any other issues?

  17. Arnt Gulbrandsen Curtis King Alexey Melnikov draft-ietf-lemonade-imap-notify-01.txt IMAP NOTIFY IETF 70 - Vancouver, Canada

  18. IETF 70 - Vancouver, Canada Open Issues • Combine Create/Delete/Rename mailbox into one event • Consensus seems to be in favour of this change • Do we want to make some events optional? • If yes, then how do we discover which are supported? • (Peter Coates) get rid of the fetch-atts on MessageNew event, move fetch-atts to CONTEXT instead • (Peter Coates) Remove message-search-criteria from the NOTIFY extension, use CONTEXT instead

  19. Dave Cridland Alexey Melnikov Stéphane Maes draft-ietf-lemonade-profile-bis-07.txt LEMONADE Profile Bis IETF 70 - Vancouver, Canada

  20. IETF 70 - Vancouver, Canada ESMTP AUTH STARTTLS PIPELINING 8BITMIME CHUNKING BINARYMIME DSN SIZE ENHANCEDSTATUSCODES BURL Profile MUST implement IMAP • STARTTLS • CATENATE • URLAUTH • UIDPLUS • LITERAL+ • CONDSTORE • NAMESPACE • IDLE

  21. IETF 70 - Vancouver, Canada Phase bis - MUST implement(IMAP, documents completed) [green – to add, red – to delete?] • All of Profile • Allow Partial URLs in CATENATE and URLAUTH (needs new IMAP capability) • Quick Reconnect (QRESYNC+ENABLE), SASL-IR • Search/sort extensions: ESEARCH, WITHIN, SORT • COMPARATOR (draft-ietf-imapext-i18n) • Views: CONTEXT=SEARCH, CONTEXT=SORT & ESORT (draft-cridland-imap-contexts-03.txt) • METADATA, LIST-EXTENDED • Bandwidth optimizations • COMPRESS=DEFLATE • BINARY (including APPEND)

  22. IETF 70 - Vancouver, Canada Phase bis - MUST implement(IMAP, work in progress) • Content Transformation: CONVERT (Static) • In-band notifications: NOTIFY (draft-ietf-lemonade-imap-notify-01.txt)

  23. IETF 70 - Vancouver, Canada Phase bis - MUST implement (SMTP) • All of Profile • Future Release SMTP (RFC 4865) ? • QUICKSTART (draft-fanf-smtp-quickstart-00) - out?

  24. IETF 70 - Vancouver, Canada SIEVE Filters (?) IMAP Sieve How to manage scripts? Need a way to control where Sieve notifications should be sent Phase bis - Optional/undecided IMAP • URLAUTH extension (draft-cridland-urlfetch-binary-00) • Storing views on the server: draft-melnikov-imapext-filters-00.txt • Extended Error Reporting (Peter Coates)

  25. IETF 70 - Vancouver, Canada Profile Bis – Other Open Issues • Support for IPv6 in servers is a MUST? • Describe what should happen if a CONVERT URL (which now returns binary data) is used in CATENATE. • Does this require a new IMAP capability? • Should this be a required extension?

More Related