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

IETF 65 – Lemonade – March 20, 2006 1

Lemonade Status Updates for IETF’65:

Our Assigned drafts for Mar 20, 2006 WG session (*)

[email protected]

[email protected]

(*) Other updates are to be presented by others and missing from this presentation

mailto:[email protected]

mailto:[email protected]


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)


New Lemonade-profile-bis features

• See section 14 of draft-ietf-lemonade-profile-bis-01


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


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


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


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


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.


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)


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?


Proposal

• In Beijing we agreed on object compression versus TLS

• Proposal: – Allow both– And allow client to determine which one is

used


draft-ietf-lemonade-search-within-00

• Status update: Applied changes agreed in Beijing– Stand alone Search within extracted from

VFOLDER



• 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



• 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?




• 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)




• 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



• Next steps:– Apply fixes discussed earlier


draft-maes-lemonade-vfolder-03

• Status update: Applied changes agreed in Beijing– Separate WITHIN extension to separate draft



• Comments:– From Jerry:

• LPSEARCH vs LVFOLDER: • Answer: It’s a mistake and it will be updated to

LVFOLDER everywhere


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



• 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.

Documents

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