1. December 6, 2007IETF 70 - Vancouver, Canada1 Lemonade Interop event in Munich

2. December 6, 2007IETF 70 - Vancouver, Canada2 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. December 6, 2007IETF 70 - Vancouver, Canada3 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. December 6, 2007IETF 70 - Vancouver, Canada4 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. December 6, 2007IETF 70 - Vancouver, Canada5 Thank you! Thank you to Arnt Gulbrandsen & Oryx for hosting the event

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

7. December 6, 2007IETF 70 - Vancouver, Canada7 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;urlaut h=submit+fred:internal:91354a473744909de610943775f92038 " BINARY) S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlaut h=submit+fred:internal:91354a473744909de610943775f92038 " ~{28} S: Si vis pacem, para bellum. S: S: a002 OK URLFETCH completed

8. December 6, 2007IETF 70 - Vancouver, Canada8 IMAP ENABLE Arnt Gulbrandsen draft-gulbrandsen-imap-enable-03.txt

9. December 6, 2007IETF 70 - Vancouver, Canada9 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. December 6, 2007IETF 70 - Vancouver, Canada10 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. December 6, 2007IETF 70 - Vancouver, Canada11 IMAP CONVERT Alexey Melnikov Peter Coates draft-ietf-lemonade-convert-12.txt

12. December 6, 2007IETF 70 - Vancouver, Canada12 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. December 6, 2007IETF 70 - Vancouver, Canada13 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. December 6, 2007IETF 70 - Vancouver, Canada14 IMAP Internationalization Chris Newman Arnt Gulbrandsen Alexey Melnikov draft-ietf-imapext-i18n-13.txt

15. December 6, 2007IETF 70 - Vancouver, Canada15 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. December 6, 2007IETF 70 - Vancouver, Canada16 Open issues (2) Internationalized usernames/passwords Any other issues?

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

18. December 6, 2007IETF 70 - Vancouver, Canada18 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. December 6, 2007IETF 70 - Vancouver, Canada19 LEMONADE Profile Bis Dave Cridland Alexey Melnikov Stéphane Maes draft-ietf-lemonade-profile-bis-07.txt

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

21. December 6, 2007IETF 70 - Vancouver, Canada21 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. December 6, 2007IETF 70 - Vancouver, Canada22 Phase bis - MUST implement (IMAP, work in progress) ✔ Content Transformation: CONVERT (Static) ✔ In-band notifications: NOTIFY (draft-ietf- lemonade-imap-notify-01.txt)

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

24. December 6, 2007IETF 70 - Vancouver, Canada24 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) SIEVE Filters (?) IMAP Sieve –How to manage scripts? Need a way to control where Sieve notifications should be sent

25. December 6, 2007IETF 70 - Vancouver, Canada25 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?