1 / 21

Lemonade Status Updates for IETF’65: Our Assigned drafts for Mar 20, 2006 WG session (*)

Lemonade Status Updates for IETF’65: Our Assigned drafts for Mar 20, 2006 WG session (*). stephane.maes@oracle.com ray.cromwell@oracle.com. (*) Other updates are to be presented by others and missing from this presentation. draft-ietf-lemonade-profile-bis-01. Status update:

sai
Download Presentation

Lemonade Status Updates for IETF’65: Our Assigned drafts for Mar 20, 2006 WG session (*)

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. Lemonade Status Updates for IETF’65:Our Assigned drafts for Mar 20, 2006 WG session (*) stephane.maes@oracle.com ray.cromwell@oracle.com IETF 65 – Lemonade – March 20, 2006 (*) Other updates are to be presented by others and missing from this presentation

  2. draft-ietf-lemonade-profile-bis-01 • Status update: • Merge of draft-ietf-lemonade-profile-bis-00 (that applied Beijing agreements) and draft-ietf-lemonade-profile-07 with some corrections • Updated references • Text improvement • Appendix on streaming attachments • Needs work and decisions… • Comments received: • Few fixes resulting from new corrections to draft-ietf-lemonade-profile. Will be fixed in next revision • Discussion of extensions (see after) IETF 65 – Lemonade – March 20, 2006

  3. New Lemonade-profile-bis features • See section 14 of draft-ietf-lemonade-profile-bis-01 IETF 65 – Lemonade – March 20, 2006

  4. Extensions proper to lemonade-profile-bis – Agreed list • IMAP extensions: • BINARY APPEND, RECONNECT (quick reconnect), support for Partial IMAP URLs in CATENATE/URLAUTH, VFOLDER, CONVERT, ESEARCH, ANNOTATEMORE (to manage notifications), COMPRESS (agreed in Beijing, alternatives discussed below), SEARCH WITHIN, • SMTP extensions: • support for Partial IMAP URLs in BURL • NOTIFICATIONS • MSGEVENTS • SIEVE IN IMAP IETF 65 – Lemonade – March 20, 2006

  5. Extensions proper to lemonade-profile-bis – Under discussion • CLEARIDLE • Use IDLE to listen to multiple folders for changes • RFC2177 is vague (even with Barry’s update that states that any response is allowed at any time) on the exact semantics of what a server MUST send in response to mail store changes. • For example, if CONDSTORE is used, does an IDLE client get any untagged FETCH responses when a STORE is performed? • CLEARIDLE+QUICKRECONNECT (efficient inband event-based synchronization) • Sieve Notify extension • SMTP extensions by Tony Finch • Dave's "headers from envelope" SMTP extension • TLS compression / Deflate and relationship to compress • Discussed under compress • XENCRYPTED => Discussed on Wednesday • Proxy / firewalls => Discussed on Wednesday IETF 65 – Lemonade – March 20, 2006

  6. draft-ietf-lemonade-notifications-01 • Status update: Applied changes agreed in Beijing • Move SMS / WAP examples to an informative appendix. • Restrict the exchange of keys via LPROVISION to secure exchanges. • Differentiate ANNOTATE from LPROVISION on that basis. • Comments received: • Bring in text from draft-ietf-lemonade-notify-s2s into the doc IETF 65 – Lemonade – March 20, 2006

  7. draft-ietf-lemonade-notifications-01 • Next Steps: • Complete the specification tasks and editor’s identified in draft-ietf-lemonade-notifications-01 • Detailed NF specifications (Sieve or no sieve) • NF filter management protocol • Fix login and session based on evolution of Quick reconnect • Clean up ANNOTATE versus LPROVISION and LGETPREFS • Bring in text from draft-ietf-lemonade-notify-s2s IETF 65 – Lemonade – March 20, 2006

  8. draft-ietf-lemonade-convert-02 • Status update: Applied changes agreed in Beijing • Fixed a normative example to be informative. • Added formal syntax for BODYPARTSTUCTURE, response text codes, and • Formal structure of composite GETANNOTATE values. • Next steps: • Standardize baseline set of conversions which SHOULD be supported for Lemonade Profile, as well as parameters. IETF 65 – Lemonade – March 20, 2006

  9. draft-ietf-lemonade-compress-00 • Status update: Applied changes agreed in Beijing • Re-cast LZIP to focus on compression of text and binary literals. • Comments: • TLS compression and draft-gulbrandsen-imap-deflate-02.txt? • Note, the experiments need to apply on attachments and compare latest compress at the minimum • This was discussed before • Some arguments for compress and object level compression have also been made (see after) IETF 65 – Lemonade – March 20, 2006

  10. Compress / Object level Compression • Especially useful for attachments • Does not make TLS assumptions still challenging for phones • Trade-off processing / power / bandwidth based on what is requested and client context • Relevant to mobile phones… • Can be requested by client: • Protocol deterministic • Not deterministic for protocol / server: • When desired by user (e.g. cost / speed / experience) • To save battery etc • Isn’t client request the norm for Lemonade? IETF 65 – Lemonade – March 20, 2006

  11. Proposal • In Beijing we agreed on object compression versus TLS • Proposal: • Allow both • And allow client to determine which one is used IETF 65 – Lemonade – March 20, 2006

  12. draft-ietf-lemonade-search-within-00 • Status update: Applied changes agreed in Beijing • Stand alone Search within extracted from VFOLDER IETF 65 – Lemonade – March 20, 2006

  13. draft-ietf-lemonade-search-within-00 • Comments: • From Arnt: • Formal syntax mistakes that will be fixed • Use OLDER/YOUNGER, instead of NOT WITHIN/WITHIN: OK • Use Day granularity: OK • WITHIN should be SINCE instead of SENTSINCE: OK need Arnt to help by showing how to correct IETF 65 – Lemonade – March 20, 2006

  14. draft-ietf-lemonade-search-within-00 • Comments: • From Arnt (Continued) • I'm not sure which of the two is more desirable. It would be possible to have both by extending IMAP differently - using "-" nz-number as an alternative to time-date in SENTSINCE and friend. Instead of SEARCH NOT WITHIN 604800, the extension could say SEARCH SENTBEFORE -7 to find messages sent more than 7 days ago. Or it could say SEARCH SEARCH BEFORE -7 to search for mail which was received more than 7 days ago. • Answer: At the time WITHIN was drafted, we felt is was probably easier to add a search key, than to introduce an entirely new interval type to all of the existing date oriented keys. What's the rest of the WG think? IETF 65 – Lemonade – March 20, 2006

  15. draft-ietf-lemonade-search-within-00 • Comments: • From Arnt (Continued) • Concern about big problem with UNSEEN: WITHIN+VFOLDER are difficult to implement correctly and effciently. Take a search such as 'UNSEEN NOT WITHIN 86400', ie. a search for all unread messages older than one day. • Answer: Not an issue, UNSEEN is disallowed by VFOLDER, no searches on dynamic attributes (or any mutable properties of messages) IETF 65 – Lemonade – March 20, 2006

  16. draft-ietf-lemonade-search-within-00 • Comments: • From Arnt (Continued) • The UNSEEN bit of the search changes only when the mailbox' modsequence increases (or equivalent for servers which don't implement CONDSTORE). However, WITHIN changes potentially every second, even when nothing happens to the mailbox. • Answer: There was an implicit assumption (not spelled out in the draft) that VFOLDER searches would only be computed when 1) a new message is placed in a backing mailbox or 2) a folder is SELECTED or 3) based on a notification server specific timer. It was not really expected that this would be computed continuously. • We agree that needs to be clarified in a future revision IETF 65 – Lemonade – March 20, 2006

  17. draft-ietf-lemonade-search-within-00 • Next steps: • Apply fixes discussed earlier IETF 65 – Lemonade – March 20, 2006

  18. draft-maes-lemonade-vfolder-03 • Status update: Applied changes agreed in Beijing • Separate WITHIN extension to separate draft IETF 65 – Lemonade – March 20, 2006

  19. draft-maes-lemonade-vfolder-03 • Comments: • From Jerry: • LPSEARCH vs LVFOLDER: • Answer: It’s a mistake and it will be updated to LVFOLDER everywhere IETF 65 – Lemonade – March 20, 2006

  20. draft-maes-lemonade-vfolder-03 • Comments: • From Jerry (Continued): • Also the first example in section 6 uses as the psearch string - (INBOX >HEADER "Sender" "lemonade-bounces") what header field is this searching or >is it searching the entire message header for either of the two strings? >What is the meaning of multiple search strings - is it "OR" or "AND"? • Answer: In RFC3501, the search-key is specified as HEADER SP <header-fld-name> SP astring. header-fld-name is defined as astring. And the semantics of the HEADER key are defined as follows: • "Messages that have a header with the specified field-name (as defined in [RFC-2822]) and that contains the specified string in the text of the header (what comes after the colon). If the string to search is zero-length, this matches all messages that have a header line with the specified field-name regardless of the contents." So the intended effect is to look for messages containing an RFC2822 header "Sender:" containing the string "lemonade-bounces" • From Alexey: No issues, they will be implemented in next revision • From Alexey: draft-gulbrandsen-imap-view-00 overlaps … • Answer: The VIEW draft contributes several semantic clarifications (on deletions, renames, etc) that are generally useful and should be in VFOLDER => Will be done IETF 65 – Lemonade – March 20, 2006

  21. draft-maes-lemonade-vfolder-03 • Next Steps • Apply fixes discussed earlier • Decide whether virtual mailboxes may have their own annotations and whether messages in a virtual mailbox may have their own annotations, both of which are not reflected in the backing mailbox. View dependent annotations may be useful for multi-device synchronization. • Determine whether section 6 conflicts with RFC3501 guarantees or any IMAP extensions, and if so, how to resolve such conflicts. IETF 65 – Lemonade – March 20, 2006

More Related