2.1.7 Enhancements to Internet email to support diverse service environments (lemonade)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional LEMONADE Web Page

Last Modified: 2005-06-27


Glenn Parsons <gparsons@nortel.com>
Eric Burger <eburger@brooktrout.com>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion: lemonade@ietf.org
To Subscribe: lemonade-request@ietf.org
In Body: in boby 'subscribe'
Archive: http://www.ietf.org/mail-archive/web/lemonade/index.html

Description of Working Group:

Lemonade is tasked to provide a set of enhancements and profiles of
Internet email submission, transport, and retrieval protocols to
facilitate operation on platforms with constrained resources, or
communications links with high latency or limited bandwidth. A primary
goal of this work is to ensure that those profiles and enhancements
continue to interoperate with the existing Internet email protocols in
use on the Internet, so that these environments and more traditional
Internet users have access to a seamless service.

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

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

- 3GPP TSG T WG2 SWG3 Messaging <http://www.3gpp.org/TB/T/T2/T2.htm>
- W3C Mulitmodal interaction Activity <http://www.w3.org/2002/mmi/>
- Open Mobile Alliance <http://www.openmobilealliance.org/>
- 3GPP2 TSG-X <http://3gpp2.org/Public_html/X/index.cfm>

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:

Done  Submit LEMONADE goals and use-cases specification to the IESG
Done  Submit server to server notification requirements to the IESG
Done  Submit translation to other messaging systems to the IESG
Apr 05  Submit IMAP/SUBMIT extensions for forward without download to IESG
Apr 05  Submit IMAP4 profile for mobile devices to the IESG
Jun 05  Submit IMAP4 extensions for streaming multimedia to the IESG
Aug 05  Submit server to server notification protocol to the IESG


  • draft-ietf-lemonade-goals-05.txt
  • draft-ietf-lemonade-catenate-05.txt
  • draft-ietf-lemonade-urlauth-07.txt
  • draft-ietf-lemonade-profile-03.txt
  • draft-ietf-lemonade-reconnect-03.txt
  • draft-ietf-lemonade-mms-mapping-04.txt
  • draft-ietf-lemonade-futuredelivery-01.txt
  • draft-ietf-lemonade-notify-s2s-00.txt
  • draft-ietf-lemonade-burl-01.txt

    No Request For Comments

    Current Meeting Report

    Lemonade Minutes

    Session 1: Tuesday 10:30-12:30

    Note Well Noted.

    Lisa Dusseault Volunteered to Jabber Scribe
    These minutes taken by Greg Vaudreuil

    • Incoming OMA liaison

    • Profile Phase 2

    • Charter discussion

    • OMA Samurai Seven (Stephan's p-imap portions)

    • Next Steps
    Glenn presented the OMA Liaison from the Mobile Email working sub-group. The slides of that presentation and the OMA liaison statement are available on the Lemonade Supplementary web-site at http://flyingfox.snowshore.com/i-d/lemonade The LEMONADE chairs were invited, and will present three contributions to the OMA MEM meeting August 8-9. Placeholder draft responses were submitted to the OMA prior to this meeting. Greg Vaudreuil presented a draft liaison statement and collected various comments not repeated here. The working group agreed to pursue an interim working group meeting held jointly with MEM, pending resolution of procedural and scheduling issues. Further comments were solicited and received from the mailing list. A revised liaison will be submitted via official IETF Liaison channels to the OMA MEM group.

    The Lemonade charter was discussed, and there was no expressed desire to make changes. The group agreed to revisit the charter again after the OMA revised and formalized their requirements and Lemonade participant digest which requirements are relevant for IETF work.

    The Lemonade goals document is not yet out of the RFC Editors queue, and it is already well out-of-date. The group discussed, but found no reason to re-open this discussion. It remains useful as background, but the charter has replaced the document as the official documentation of accepted goals. Any additional use-cases needed will be incorporated into the profile document itself.

    The chairs presented the set of candidate standards to include in Lemonade phase 1. Of note:
    • Quick Reconnect is now considered stable and will be in Phase-1

    • Sense of room is that future delivery will be not be part of Phase-1, but may be part of Phase-2.
      • It should continue to progress independently of profile 1 for now.
    • All requirements in Lemonade will be "MUST" and apply to the server. Shoulds and May's increase the number of combinations and will raise implementation complexity for what is a understood to be a limited client.
      • OMA or others can write behavioral requirements against the client.
    Phase-2 of the profile will include additional new protocol work as needed and will also include explicit requirements for pre-existing IMAP and SMTP-Submission extensions. Phase-1 is not intended to be complete, but to include a useful subset to include primarily the forward-without-download.

    Session 2: Wednesday 10:30-12:30

    The second session was focused primarily around Phase-2 of the Lemonade profile.

    Ileana gave a brief review of the OMA process and solicited clarification on the IETF process. Glenn Parsons offered a possible schedule for deliverables from lemonade, and the two figured out in real time what that might mean for various OMA deliverables including the requirements and the IOP test case. Also clarified was that the OMA MEM meeting held the next week, August 8-9 was not a joint meeting, and could be attended only by OMA members and Eric Burger as an invited expert to present the work of the Lemonade WG. OMA can meet jointly on in the form of a workshop where no decisions are taken.

    Next was a discussion on Server to Client notifications, a prominent area of requirements from the OMA. There are inband notifications that can be provided by IMAP when the client is connected to the server, and out-of-band notifications via an available signaling channel. It was noted that IDLE does not provide notifications for any but the selected mailbox, but that CLEARIDLE offers the ability to monitor several mailboxes.

    Non-IMAP notifications are out of scope for LEMONADE, but there is work within the SIEVE working group that may be directly relevant. In particular the SIEVE rules may include criteria to send a notification and a specification of what that channel might be. It was noted that SIEVE implemented in the Message Deposit Agent (MDA) will not see events for mailbox state changes. After an interesting discussion, several folks agreed to offline discussions to discuss how SIEVE and the various mailbox status change events might be filtered and delivered in a semi-consistent state. (why send a SIEVE new message event and a mailbox-initiated new mail event for example)

    In the big-picture, there is charter text asking for Lemonade to pause on work for notifications for big-picture advise on the relationship of the large and growing numbers of application specific and general notification schemes proliferating within the IETF including XMPP, SIP, and WebDav. The charter language requesting consideration of IAB feedback on server-to-server notifications was reviewed and the AD's took an action item to determine what to do with the "embarrassing" charter language and/or IAB input. After the meeting Scott Hollenbeck identified the relevant IAB response, apparently lost previously in the noise.

    With the caveat of the language, a discussion was held on whether server-2-client notifications should be within scope of Lemonade. Discussion of a new WG or expanded Lemonade of SIEVE charter were discussed. A straw poll to gauge interest in S2C work was made, with the AD's recognizing enough interest to let the conversation proceed. Rather than debate without a proposal, Stephan Maes took an action item to define a work item. The chairs agreed to translate the contributed text into "high charter English" and send to the WG for comments. Chris Newman offered to write up a draft on notification triggers and formats useful for email, explicitly without discussing possible transports..

    In the remaining time, Stephan gave an overview of some of the P-IMAP derived contributions into the IETF. In some cases the drafts will be withdrawn where they are duplicative, such as UIDPlus and Monoinuid. Others such as XFILTER will be considered as options to address
    requirements in Phase-2.

    The chairs solicited hosts for an interim WG meeting. The interesting case of holding a meeting in conjunction with the OMA meeting in Sydney does not work per IETF interval restrictions (too close to next IETF plenary). Scheduling will move to list and dialogue with OMA will be opened via the liaison reply.

    Meeting Adjourned.

    Respectfully submitted,

    Greg Vaudreuil

    Lemonade Minutes: Narrative
    Lemonade - Day 1

    Edwin is scribing, Tony is Jabbering

    Jabber Logs: http://www.xmpp.org/ietf-logs/lemonade at xmpp.ietf.org/

    Agenda Bashing
    The chairs noted one unlisted item on the agenda: a discussion at the end of day 2 of where we should go next, specifically whether there will be any additional interim meetings.

    No other comments to the agenda

    Status of Documents - Chairs

    Goals doc is (still) in the RFC Editor Queue
    • 30 of the references are reported dangling; need to verify that text hasn't been lost
    Server to Server notification requirements
    • Updates needed from IESG comments; author has reappeared and confirmed that he will make necessary updates to the document

    MMS Mapping
    • IESG approved, appealed, approval rescinded, new draft needed (details to come later today)

    Forward without download trio
    • Currently in IETF last call, pending IESG review

    • Q from Ted: were we planning to do anything with Randy's comments (on BURL and CATENATE)? Incorporate as an RFC editor note or were there other last call comments? Chairs will put together a summary and verify that there weren't any other last call comments. Meanwhile, Randy summarized his comments on the trio docs:

      • BURL: most were minor; Chris offered to do a quick rev to incorporate comments if it won't cause hiccups in the process

      • Catenate: minor typos, but pointed out that the draft contains no normative language. Randy asked to verify that's the direction we want to go. Ted asked whether anyone found the lack of normative language a concern for implementation? No one took issue with the lack of normative language.

      • URLAUTH: Randy had some additional comments that haven't been sent yet.

    • Edits to be incorporated and sent to Ted for IESG review

    Future Delivery
    • WGLC closed; was going to create a new draft before IETF last call

    • Sent to editor past the deadline for this meeting.

    • Will request IETF last call on the new draft

    • Changes were minor nits: clarified security session to reflect Feb. Minneapolis changes; IESG comments to make changes to the IPR header and other minor normative references; other minor changes based on comments

    • There was a discussion, initiated by Pete, about whether we wanted to tackle the reconnect issue in LEMONADE as an application-level issue or look at it at the transport layer:

      • Pete suggested that perhaps we could defer to shim6, but others observed that shim6 did not have any IPv4 in its charter. Others were uncomfortable with having a critical path dependency on shim6.

      • Other technologies that are looking at this: HIP and others

      • Keith suggested that a nearer term solution might be TLS.

      • Ted pointed out that there are at least 10 active efforts looking at this problem at the internet architecture layer, and Phillip added that there are two in LEMONADE as well.

      • The IPv6 co-chair mentioned he would like to get input or feedback from here into the applicability document to help motivate shim6 work.

      • Dave suggested formulating the question into what this application layer needs from a transport layer below.

      • Glenn: The solution for IMAP is within our charter and is something we want to do. In the profile document, should specify that there are multiple options. There seems no reason to pull this from our set.

        • Some elements are absolutely needed: e.g., delta set notification; can pull out the connect/reconnect and put that in the lower layers if needed.

        • Should we make it experimental? Some dissent; comparison to VPIM from some years back.

      • Eric: We had this conversation before. Reconnect doesn't harm anything; has some useful characteristics, would recommend going forward:

    • WG agrees to go forward with WGLC

    Intermediaries and S2C Notification Requirements
      • Discussion deferred to phase 2 (tomorrow)

    MMS Mapping - Randy Gellens

    • -04 approved by IESG but appealed

    • Issues discussed on list ~6/10-7/5

    • Looks like consensus on x-headers ~6/28

    • IESG resolution allows group to revise and go through an additional cycle of WGL

    • Very little group discussion after -02

    • "SHOULD" retain X-MMS-Message-ID

      • Concern that that language standardized X-headers; delete any text of retaining X-MMS headers

    • Maps X-MMS-Priority to both X-Priority and Importance

      • Concern that this was standardizing X-priority; result: not map to X-Piroirty but mention it in an informative section

    • Suggests using comment instead of group syntax to indicate sender address hiding

      • Invalid for 2821

    • ESMTP vs. SMTP

      • Talks about ESMTP and SMTP mostly merged; appeal felt that this was a violation of ESMTP - all new mentions should be of ESMTP; most of the SMTP text can be removed

    • Text on address hiding in

      • MMS systems employ this, so if a gateway receives MMS message intended for the Internet.

      • Some discussion about whether this text should be there.

    • Text on media conversion in content-type in

      • If you receive a message from MMS not in widespread use on the Internet, potentially downconvert it

      • Any advice about content conversion should be left silent

    • Language on gateways and relay servers

      • Can probably just be edited

    • Statement about 2821 for null return-path to prevent mail loops

      • 2821 does not actually require it; may want to clarify the wording

    • Resent-Count header

      • Not standardized anywhere: suggestion to delete mention of resent count

    • Text on quoting and Resent and Received headers in

      • Suggestion from appeal was to delete this section in its entirety

    • Lack of specific response code in "sensitivity" text

      • Need to be more specific about what response code to send back

    • Security Considerations

      • Had a bunch of text that the appeal objected to

      • Much of the text could probably be deleted

    • MMS references not normative

      • This introduces some other considerations for the requirements for normative references

    • Bcc example in section 3 is incorrect

    • Handwaving on creating Message-ID

      • Text could potentially be made more rigorous

    • Needs text on unqualified addresses

      • Proposal: unqualified addresses should be rejected

    • Text on anonymous remailiers and signed mail in section 3 is "silly"

      • Could probably be deleted

    • Incorrect or incomplete text in Section 3 (SMTP auth, S/MIME, PGP)

      • Text will need to be looked at

    • Semantic mismatches between the Diposition-Notififcation-To header in [MDN] and X-MMS-Read-Reply header

    • X-headers issues resolved on list

    • Do need some discussion on

      • Sender address hiding

    • Normally, within Internet protocols, the message will be sent through the system and rely on the UA to remove the address; obviously doesn't work for Internet mail

    • Can include text on why sender address hiding is a bad idea

    • Not much comment from the room.

      • Usefor (Usenet format) WG was requesting a similar feature; there was some desire for this

      • Glenn: VPIM: Unknown was created for this purpose (unknown@domain); but domain was known

    • Randy could clean up text to indicate that we are not supporting sender address hiding but include some more text that does the semantic mapping

      • MDN vs. MMS read-reply

    • Discussion taken to the list

      • Require null return path for automatically-generated messages

    • Is there a reference to RFC 3834 in the draft?

    • Suggestion to propose specific text to the list and encourage discussion

    • Other text changes needed (-05) and will resubmit for last call

    Lemonade Profile
    Changes Since -02
    • Changes are mostly editorial

    • More substantial changes:

      • Updated examples to match the current trio docs

      • Some clarifications on using TLS, but this section still needs more work

      • Qualified normative statement on future delivery ("SHOULD" downgraded to "MAY") but this is still an open issue

    Open Issues
    • Randy: is quick-reconnect part of v1?

      • A: Previous discussion leads me to believe it is, so current text and examples need to be expanded

    • Randy: is future delivery part of v1? Not a good idea to have too many optional features; need to determine whether it is mandatory or optional

      • Comment in favor of keeping it mandatory

      • Randy: If they are part of the profile, then they need to be mandatory so that the server can say that it supports it and write a simple client

    • The group entertained a lengthy discussion about what it meant to be "Lemonade v1 compliant"

      • Eric: there is still no bulk capability negotiation; each extension is still individually specified, so is compliance really a marketing issue?

      • Stephane: Nothing prevents us in the future from have a bulk set of properties.

      • Dwight Smith: How is the profile handled on a process perspective? Is there a compliance statement? A: It's a squishy concept; there is no bulk negotiation for lemonade compliance. Profile document summarizes a set of standards that is used for a particular application. Intent is that it's a bundle that allows implementers to look at a single place for implementation. Pete: There's nothing to stop OMA from pointing to this document (for example) and indicate that this is their compliance document. Profile document also has a bunch of applicability statements that are useful.

      • There was a question if the profile document was intended to be normative? If yes, then there are ambiguities.

    • Profile document is useful to specify a bundle of extensions

    • And to inform clients as to how to use the various extensions to accomplish a specific task

      • Stephane: At the end of the day, an implementer needs to implement mobile email. OMA Mobile email doesn't require future delivery; including future delivery within Lemonade means that an OMA client must implement it in order to be Lemonade compliant.

      • Philosophy question: should a profile be the smallest possible set of aggregation to implement a particular set of functionality.

      • Randy: Reason to have a normative profile is for implementers that create clients on constrained platforms to avoid having to create code paths to deal with servers that implement parts of it.

      • Chair position: profile v1 as specified here is in charter and we're doing it. The OMA liaison will help direct phase 2.

      • No clear consensus: take this to the list

    • Randy: TLS Section needs more work

    • Draft editing/catenation examples are omitted

      • Randy: if they're in catenate, then they don't need to be here; agreed

    • Need to select which extensions are mandatory and which are optional:

    Mandatory/Optional IMAP Extensions

    • STARTTLS - MUST (RFC 3501)

    • CATENATE - MUST (Fwd w/o download)

    • URLAUTH - MUST (Fwd w/o/ download)

    • UIDPLUS - Suggest MUST (makes things easier)

      • Has to be a must; without UIDPLUS, you don't get the UID back to create a CATENATE URL


    • RECONNECT - yes, see above

    Mandatory/Optional SMTP Extensions
    • AUTH - MUST required by Submit

    • BURL - MUST (Fwd)

    • FUTUREDELIVERY - taken to list

    • PIPELINING - suggestion: MUST (SHOULD)


    • 8BITMIME - MUST (required by BURL)



    • DSN

    • SIZE


    • We should do those things as MUST that a mobile environment would think of us looney for not having

    • In order to simplify clientimplementation, we shouldn't have any SHOULDs; everything should either be MUST or MAY

    • Some discussion on whether you need 8-bit downconversion if 8BITMIME is a MUST


      • Chris expressed a concern over whether STARTTLS should be a MAY from a security perspective

    • Concern was that STARTTLS was not implemented in mobile handsets

      • John suggested STARTTLS and CRAM MD5 are orthogonal; STARTTLS can be a MUST, but we should also have CRAM MD5

    • Discussion about whether plain vs. MD5 passwords on the server are more secure. Assertion is that server passwords could be made more secure by using plain and implementing additional preprocessing on the server.

    • Keith: argued that CRAM MD5 is likely to be deprecated shortly; it seems awkward for us to suggest the use of CRAM MD5 at about the time that they're likely to be deprecated.

      • Randy: OMA requirement is mutual auth; plain doesn't satisfy this requirement. TLS with expired or self-signed certs is also a reality.

      • Proposal from Chris: Plain w/ STARTTLS is mandatory to implement, not necessarily mandatory to use.

      • If we want STARTTLS due to security, we need to also specify a minimum cipher suite.

      • Chris: We can't mandate that implementations be secure, but we can say that unless a set of recommended system is

      • Eric: Concern is that people don't tend to pick particularly good passwords. C/R schemes: server needs to store the same set of credentials that the client generates to validate the password.

      • Consensus: STARTLS is a MUST; FUTUREDELIVERY will be taken back to the list; everything else is a MUST

    Next steps:
    • Is there sufficient work to submit a new draft, or does the FUTUREDELIVERY work need to be done?

    • Needs from the mailing list: FUTUREDELIVERY and a syntax for RECONNECT

    • The chairs took a hum to see if Future delivery should be part of Profile v1.

      • There was clear consensus in the room that future delivery should not be part of Profile v1.

    • Those with strong objections should note on the list within a week

    OMA Collaboration
    • RFC 3975 describes the framework of collaboration with IETF

    • Desire for most work to happen at the WG level, but where necessary, the liaison ensures specific processes for interaction.

    • Working closely with Dean Willis

    • Once the liaison is established, the intent is to synchronize requirements which are, in general defined in OMA, with protocol specifications which will be defined in IETF.

    • IETF members have access to OMA's normative dependencies for 3 enablers:

      • PTT (Push to Talk)

      • Presence

      • XDN

      • Some additional normative references for IM/SIMPLE

    • Once requirements are relatively stable, OMA looks to IETF, 3GPP, and 3GPP2 for common work. If something is going on within the IETF, OMA will not replicate that work but will contribute to the discussion in that group.

    • Every two months conference calls between OMA and chairs from the appropriate group; identify issues and drafts which are not stable.

      • Currently, only 2 drafts identified as not stable that are necessary for the work to proceed.

    • Q: Right now there are no lemonade dependencies; do we expect that will change? A (Stephane): Work within OMA to date has been requirements; architecture work has started, so we would expect that additional dependencies on LEMONADE will come.

    OMA Mobile Email Liaison

    Liaison Request
    • Considers the OMA Mobile e-mail requirements as input from the mobile community in terms of requirements for mobile e-mail features that may affect the LEMONADE Activities

    • Provides feedback on the possible relevance of LEMONADE work

    • Provides its view on preferred potential collaboration

    • Encourages participants who work for OMA member companies to accept the invitation to attend the OMA Mobile E-mail SWG interim meeting

      • Suggestion about whether we should have joint meetings in the future.

      • Stephane pointed out that OMA can have workshops, but not have decision-making meetings with non-OMA members.

      • Suggestion that the LEMONADE response include a list of documents that apply

    IETF Response
    • Lemonade chairs will present at OMA Mobile Email interim 8-9 Aug. in Paris. Topics will include:

      • What is LEMONADE

      • What is Internet Email

      • Comments on requirements

    • Drafts on these are on the supplemental site

    • Comments welcome this week

    End of Lemonade Day 1


    Lemonade Chairs Slides
    Lemonade Profile
    Lemonade MMS Mapping
    New Work Proposals
    Lemonade OMA Requirements Analysis