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
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.
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 Internet-Drafts:
No Request For Comments
Current Meeting Report
Lemonade Minutes
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
presented.
* Submit Intrinsically
Submit through IMAP
Notes :
Queueing of messages
Generate DSNs
Relaying
Like Sendmail functionality in IMAP
* Proxy method
Redendency in operation
Issues in athentication/Authorization
Complexity
Administrationissues
- Various alternate mechanism by which IMAP PULL can be done were
presented.
* Submit server access IMAP for messages
* Per-Mailbox access keys
* URL includes time/role/user and signatures using mailbox
secrets.
- 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.
Changes :
Authid and Authrole are included
HMAC-MD5
Upcoming changes :
Generate the secret key on demand.
Hash function
Default configuration
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
experimentation.
- 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
decided.
+ IMAP4 Profile
+ S2S notification by Gev
documents out-of-scope is descibed :
subscription
Notification service.
+ What it does :
User identifcation
Server notification service
Store and Forward
Reliablity
Event ordering ( Queue / Time stamp )
Dynamic structure ( Structure should be dynamic with respect to the
notification request )
Security
Should extensible enough to take care of end-end notification in
future
Discussions :
- this draft is not listed on the work group items but it was sent to
mailing list
- Requirements were not clear
Explicit boundary should be defined
Structures
Semantics required
Event naming required
Milestones :
Jan04 : Goals, S2S, Streaming multimedia
Apr04 : Forward without download documents
Jun04 : Profile for Mpbile devices
Jul04 : Translation to other msg systmes.
Milestones should be
Slides
Agenda
IMAP URLAUTH
MMS Mappings
draft-lemonade-imap-submit-01.txt
Server To Server Notification protocol requirements