new drafts towards phase 2 of lemonade

Nov 09, 2005IETF 64 - Lemonade

1Towards Lemonade Profile Phase 2

New Drafts Towards Phase 2 of Lemonade

Stéphane H. Maes, [email protected]

Ray [email protected]



Starting to address these issues:Proposed new drafts

• draft-ietf-lemonade-convert-00

• S2C notifications and Filters:– draft-maes-lemonade-notifications-filters-how-to-01

– draft-maes-lemonade-notifications-server-to-client-01

• draft-maes-lemonade-lzip-02• Remote editing:

– Issues on realizing LDeliver capabilities with trio, IMAPURL and Byte Ranges

• Virtual folders– draft-maes-lemonade-vfolder-01

• Intermediaries and firewalls:– draft-smaes-lemonade-intermediary-challenges-03– draft-maes-lemonade-http-binding-03



CONVERT• draft-ietf-lemonade-convert-00:

– Started from draft-maes-lemonade-lconvert-01 and implemented London agreements

– Comments received from Alexey to be implemented in next revision



S2C Notifications• draft-maes-lemonade-notifications-filters-how-to-01

– pointing to draft-maes-lemonade-notifications-server-to-client-01

– Comments from Alexey: OK to be implemented

• Capability Descriptions – draft-maes-lemonade-notifications-server-to-client-01

defines how CAPABILITY can be used to support

– determination of support of server to client notification, filtering

– and filter updates…



S2C Notifications• Event-based synchronization

– draft-maes-lemonade-notifications-server-to-client-01 describes how event-based notification can be performed. This includes a payload specification for outband notification based on OMA-EMN and possible extensions.

– Inband notification is achieved via IDLE. • Could be optimized? (see clearIDLE, Checkpoint, …) (not yet in

draft-maes-lemonade-notifications-filters-how-to-01)

– draft-newman-lemonade-msgevent-00 provides a list of possible events that could be notified

– (based on the filter settings).



S2C Notifications

• Filters – SIEVE provides an email filtering language. – draft-ietf-sieve-notify provides mechanisms to

generate notifications – based on the SIEVE filter.

• To extend as NF, VF – see Lemonade realization diagram (not yet in draft-maes-lemonade-notifications-filters-how-to-01)



IETF LEMONADE Notifications

ESMTP

ESMTP

IMAP

SUBMIT

MTA

URLAUTH

LEMONADEIMAP Store

LEMONADESubmitServer

MTA

MobileNotification Magic

Wireless Protocols(WAP Push, SMS, …)

MUA

Non-IETFStuff

IETFStuff

Content Flows

DF

NF

VF

Manage SIEVE?

AF

NotificationStuff



S2C Notifications• Next steps

– Define ways to support NF/VF and set from client (not yet in draft-maes-lemonade-notifications-filters-how-to-01)

– SIEVE filters should be extend to support generating notifications based on draft-newman-lemonade-msgevent-00 to support the notions of messages of type A, B and C and view, notification and event filters described in OMA MEM AD.

– The payload should follow draft-maes-lemonade-notifications-server-to-client-01 (OMA MEM + extensions?)

– Notifications target the email client through other notification servers or enablers. The notifications should be sent to the appropriate server.



S2C Notifications

• Checking notification settings – Mailbox annotations provide additional

mechanism for the client to determine server settings as discussed in draft-maes-lemonade-notifications-server-to-client-01.

– draft-maes-lemonade-notifications-server-to-client-01 also provides an inband mechanisms to determine these.



S2C Notifications• Changing notification settings

– draft-maes-lemonade-notifications-server-to-client-01 provides an inband mechanism to set / change notification and server settings

• Changing filters from the client – draft-maes-lemonade-notifications-server-to-

client-01 provides LFILTER as a way to update inband the filters from the client.

– See VF/NF updates (see lemonade realization diagram) (not yet in draft-maes-lemonade-notifications-filters-how-to-01)



S2C Notifications

• Out of scope items:– Specific bindings for SMS (SMS binary, WAP

Push) notifications. – OMA client provisioning and device management

and other provisioning specifications (e.g. SMS based)

– OMA enablers to support outband notifications.– OMA XDM may be considered also for outband

filter changes.



VFolder• Create virtual folders

– Permanent searchs– Support VF for mobile view etc…

• Inspired from P-IMAP LPSEARCH• Comments received from Alexey to be

implemented in next revision• Proposal to make Lemonade WG IETF draft• Issue / question:

– Need to reserve some folder names (inbox, outbox, …)?



Compression

• Mobile clients (GPRS, 1xRTT) are bandwidth constrained

• Mobile bandwidth is expensive

• IMAP is a verbose protocol

• Experiments have shown dramatic compression ratios of IMAP response sequences are achievable



Solutions• Transport Layer Security (TLS) compression

– But, not all TLS implementations support compression

– Deployment of a codec specialized for IMAP may be infeasible

• Application level encryption– New IMAP extension LZIP

• Wraps an IMAP command and indicates to the server to compress all server generated responses using ZLIB

• Defining specialized compression dictionary may be desirable



LZIP Example

C: A001 LZIP A002 FETCH 1:* ALL

S: * LZIP ~{1234}

S: ...[zipped response to FETCH command]...

S: A001 OK LZIP completed



LZIP Compression example ratios600 messages in INBOX

1064/2003 (53.1%)UID FETCH n BODY[1]249/465 (53.5%)SELECT INBOX3144/20408(15.4%)UID FETCH 1:* FLAGS

RatioIMAP Command



Compression

LZIP (defining compression at the application layer) allows some clients to achieve compression without a full SSL/TLS implementation, or where the server does not support the right set of cipher suites, or where an application protocol sensitive codec may be desired

Comments

1 minimumMinimum 2+RoundtripsZLIB + cpu overheadTLS/SSL stack + CPU

overheadComplexity

LZIPTLS



Remote Editing• Implementing LDeliver functionality with trio and IMAPURL



OMA Requirements

• USAB-21 “The mobile email client MUST allow the user to edit a partially downloaded email, for reply and/or forward and have the server send all the portions of the edited email while minimizing the amount of data that is sent to the server (e.g. sending the differences)”

• USAB-25 “When replying to a list of addressees, the mobile email client MUST allow the user to edit the addresses without downloading or uploading the whole list of addresses and minimize the amount of data that is sent to the server”



Approaches

• IMAPURL can be extended to support partial fetch of body sections (the ‘ipartial’ grammar extension). This allows CATENATE to operate on text at a smaller granularity.

• IMAPURL and IMAP could also be extended to allow header address fields to be treated as lists which can have range operations applied, or partially fetched



Use Case

• Reply To All/Group with large recipient list

– Selectively remove or append recipients to list



Problems

• Composed header fields could be edited

• Construction of SMTP Envelope isn’t handled

• BURL doesn’t allow fetching IMAP data for envelope. Need SMTP extension as well?

• Is use case too rare?



SMTP Extension?

• Extension parameter for MAIL/RCPT to fetch from a URL?



Discussion

• Ideas for solutions and syntax?

• Security issues

– Sending spam also becomes very efficient over low bandwidth links



Intermediaries

• draft-smaes-lemonade-intermediary-challenges-03– Per London AI discusses main issues:

• IDLE life time on mobile network (2.5G and even worse on 3G network)

– Battery implications– Time out of intermediaries– TCP vs HTTP:

» IDLE over HTTP has much longer life time

• Firewall issues



HTTP Binding• draft-maes-lemonade-http-binding-03• Optional use of HTTP as binding for IMAP

– Address time out differences– This binding is intended to facilitate the use of IMAP in deployments involving a

variety of intermediaries• offers a standardized alternative to de facto proprietary implementations of such a

feature.– HTTP allows operators to reuse similar setup and model already used for many

other similar and related services, e.g. certain proprietary push e-mail and synchronization offerings, OMA Data Synchronization, Web services and Web access.

– Using HTTP/HTTPS can simplify deployment in a corporate network through the potential use of a reverse proxy .

– Also has the advantage of not requiring changes to any firewall configurations and reduces deployment concerns that this often presents to corporation.

• In general the solution is compatible with any existing firewall. – A reverse proxy can also support deployment models that offer roles to other

service providers in the value chains, as discussed in OMA Mobiel e-mail AD• Based on LDELIVER disposition:

– Binding for submit on HTTP• Added security / section on caching issues



HTTP Binding

• Follows HTTP message model and error• Follows RFC3205• Plan to generate bindings on:

– SOAP– REST– WebDAV

• Proposal to analyze these bindings too and then decide best way forward

new drafts towards phase 2 of lemonade

Documents