Last Modified: 2004-01-22
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
1645.Lemonade Minutes
IETF-59
Jabber Scribe: Tony Hansen
Agenda accepted as revised
WG attendees affirmed consensus to not extend charter to create a
general composition protocol.
WG reviewed WG documents without presentations
- Goals: Awaiting ID Nits review, then WG last-call
- Channel: On hold pending Push/Pull decision
- MMS Mapping: No dependencies, waiting for WG attention .. doc is
expired
- Update with substantial additions ready for posting in a
few weeks
- S2S Notifications: In Nits review prior to a WG last-call
- Medis Size: an individual contribution slated for AD review need
update reflrecting neds comments
- Future Delivery:
- defer decision on wg status till af5ter push/pull
- Sense of room on whether revocation is an important
requirement
- Group hum suggests most see revocation is a "nice to
have",
small group thinks it is a requirement
Push vs Pull discussion
- Chair presented market realities, demonstrating haste is of
essence
- Alexi presented overview of pull mechanism, sense of room
requested on
- Sense that need to pick a pull proposal to know what
group is humming for.
- Some desire to have a hybrid option between options 2 and 3
- Peter Presented Push draft
- No presentation made (so scribe has to type)
Practical stuff
- Afraid folks will implement push anyway... and do
it wrong.
see M-IMAP.
- Is pull easily understandable? Depends upon the
varient Security
- The space does not seem fully understood
- Push seems more secure .. fewer clients to
authorization DB Architecture issues
- Not sure why push is long-term limited as
asserted GV mentioued a fourth, race conditions
Open Discussion
- Notes
Slides
Agenda
P-IMAP Draft Overview