Last Modified: 2003-10-01
Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items:
0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address.
1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server.
3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort.
4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications.
5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent.
Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability.
The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above.
The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above.
The working group is aware of several related activities in other groups:
- 3GPP TSG T WG2 SWG3 Messaging
The goal is to coordinate efforts with at least these groups as
While there is obvious synergy, given the end-of-life of the VPIM and
FAX work groups and the similar membership, the working group does not
expect to coordinate with these other groups.
Goals and Milestones:
Jun 03 Submit LEMONADE requirements and architecture specification
to the IESG Jul 03 Submit server to server notification protocol to the IESG Sep 03 Submit IMAP4 and message submission extensions for
streaming multimedia to the IESG Nov 03 Submit IMAP4 profile for mobile devices to the IESG
No Request For Comments
Current Meeting Report
Nov 10 2003 - Monday - 1.00pm - 3.00pm
+ Agenda was described as the starting item by Glenn
+ Goals of lemonade by Glenn
- Describes Uses cases and possible scenarios.
- On context and motivation
- De-emphasize on the requirement aspect
+ MMS Mapping by Randall
- Update to the existing draft would be "Mapping of delivery of msgs in
MMS world and eMail world"
- The biggest change in the pending update is the addition of mapping
between delivery and disposition reports in the MMS and Email worlds.
+ IMAP Push/Pull started by Glenn
- After the presentation, decision to be made on which approach to go.
+ Submit without download by Randell
- Depending on who is the activie entity IMAP Push and Pull are
differentiated, ie., whether IMAP server or the Submit server
- Various alternates mechanism by which IMAP PUSH can be done were
* Submit Intrinsically
Submit through IMAP
Queueing of messages
Like Sendmail functionality in IMAP
* Proxy method
Redendency in operation
Issues in athentication/Authorization
- Various alternate mechanism by which IMAP PULL can be done were
* Submit server access IMAP for messages
* Per-Mailbox access keys
* URL includes time/role/user and signatures using mailbox
- IMAP COMPOSE
Resolves many issues
Independent of PUSH and PULL
- URL AUTH
Expiry time/User identity/Role identity were described.
+ URL Auth by Chris and Mark
One of the pull method.
Authid and Authrole are included
Upcoming changes :
Generate the secret key on demand.
There was a long discussion oon URL AUTH,
- When the secret should be generated.
- Who creates the Ticket, Client or Server. Ans : Client
- Round trip in getting the tickets
- To be decided : Secrets per mailbox or per user.
- Specify both mechanism in the document.
+ Scalable mail environment by Chris:
If the message store, outbound MTA and inbound MTA are
seperated, significant performance boost was observed during his
- Security concerns in URLAUTH were discussed :
* TLS Protection
* Should not store URL without protection.
- Where the queue should be, is not specified.
- Document should be free from assumptions
+ IMAP COMPOSE by Pete
- Simplifies other uses.
+ Decision on Which way 2 go : PUSH Vs PULL
Currently we dont have enough technical details to make a decision
Before deciding, deployment cost should be considered. Make the
changes in one place or two places. Arugment was that in Pull method, both
IMAP and submit server should be touched.
Concentrate on this (email)specific problem and work on a
solution. Dont try to get a generic solution righ now.
Current specificatoin impact on Scalable mail were desribed.
NOTE: There should be a revisions of COMPOSE, Push and Pull method
drafts by Dec 17. After which the decision on which method to follow will be
+ IMAP4 Profile
+ S2S notification by Gev
documents out-of-scope is descibed :
+ What it does :
Server notification service
Store and Forward
Event ordering ( Queue / Time stamp )
Dynamic structure ( Structure should be dynamic with respect to the
notification request )
Should extensible enough to take care of end-end notification in
- this draft is not listed on the work group items but it was sent to
- Requirements were not clear
Explicit boundary should be defined
Event naming required
Jan04 : Goals, S2S, Streaming multimedia
Apr04 : Forward without download documents
Jun04 : Profile for Mpbile devices
Jul04 : Translation to other msg systmes.
Milestones should be
Server To Server Notification protocol requirements
The goal is to coordinate efforts with at least these groups as required.
While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups.