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

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. 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: 2004-11-01


Glenn Parsons <gparsons@nortelnetworks.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 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

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

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

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
Oct 04  Submit LEMONADE goals and use-cases specification to the IESG
Oct 04  Submit server to server notification requirements to the IESG
Nov 04  Submit translation to other messaging systems to the IESG
Nov 04  Submit IMAP/SUBMIT extensions for forward without download to IESG
Jan 05  Submit IMAP4 extensions for streaming multimedia to the IESG
Feb 05  Submit IMAP4 profile for mobile devices to the IESG
Mar 05  Submit server to server notification protocol to the IESG


  • draft-ietf-lemonade-imap-channel-02.txt
  • draft-ietf-lemonade-goals-04.txt
  • draft-ietf-lemonade-catenate-02.txt
  • draft-ietf-lemonade-urlauth-03.txt
  • draft-ietf-lemonade-profile-00.txt
  • draft-ietf-lemonade-msg-context-00.txt
  • draft-ietf-lemonade-reconnect-02.txt
  • draft-ietf-lemonade-mms-mapping-01.txt
  • draft-ietf-lemonade-server-to-client-notifications-00.txt
  • draft-ietf-lemonade-futuredelivery-00.txt
  • draft-ietf-lemonade-notify-s2s-00.txt
  • draft-ietf-lemonade-burl-00.txt

    No Request For Comments

    Current Meeting Report

    November 8
    November 10

    Slides are at http://flyingfox.snowshore.com/i-d/lemonade/slides61/index.html

    Minutes by Tony Hansen

    Agenda Bashing (Chairs) 5 min
    [12:04:57] agenda was modified to accommodate those who could be here on monday, not on wed, and vice versa
    [12:06:09] today: mms mapping, future deliv, urlauth, burl, catenate, quick reconect; nonWG: mobile sync, clearidle, message filter
    [12:06:28] bash: pease move quick reconnect to wed
    [12:07:00] wed agenda: Mon recap, profile & goals, quick reconnect, transcoding discussion (channel)
    [12:07:14] sold

    Charter & Liaisons (Chairs) 5 min
    [12:07:18] status update:
    [12:08:27] charter review: goals, imap ext for vm playback, submit extensions for forwarding, exts for diverse endpoints, server to server notif. protocol (not server to client), translation to/from other messaging systems
    [12:08:38] summary of deliverables
    [12:10:20] recap of interim meeting in vancouver
    [12:11:54] objectives: various drafts have moved forward, and some gone to LC, hopefully rest to WGLC before next ietf
    [12:13:04] WGLC status: server to server notif reqts: closed; mms mapping: issues to be resolved; future delivery: discussed today; goals: discussed on Wed

    MMS Mapping (Randy) 10 min
    [12:13:33] randy gellens: mms/email mapping
    [12:14:15] 01 includes explicit vpim support vs. 00
    [12:15:22] open issue: specifies the use of precedence: Bulk header; do we need it? Do we keep it? Standardize it?
    [12:19:16] discussion pro & con, mild support both ways
    [12:24:57] resolution of 'precedence: bulk' was to leave it since it is in the registry
    [12:21:18] open issue #2: sender address hiding using x-anonymous extension to MAIL FROM
    [12:22:53] support for standardizing the anon facility separately
    [12:23:58] resolution: remove it, for possible future standarization

    Future Delivery (Greg)
    [12:24:37] Greg Vaudreuil: future delivery
    [12:24:57] issues: 1*9digit; resolution leave it
    [12:25:51] issue #2: auth reqt is redundant
    [12:27:56] resolution: leave it to smtp-submit to move forward and remove from this doc, change smtp-submit reference to new doc (currently in queues)
    [12:28:12] issue #3: fix reference to rfc 2119 language
    [12:28:32] issue #4: is there a minimum futuredeliver time? does the server need to announce it?
    [12:29:26] no, doesn't add any real value
    [12:30:16] issue #6: add DOS wording to security reqts. Chris Newman is voluteering to review it closely
    [12:30:35] issue #5: odd cases in max delivery interval; 0, 9999999999
    [12:31:12] resolution: require the advertisement
    [12:31:28] various nits
    [12:31:23] Randy: why require advertisement? Answer: consistency
    [12:34:40] new drafts for mms and future delivery will come out soon (next week)

    Pull Documents URLAUTH (Chris) 5 min
    [12:34:59] chris newman: urlauth, burl, catenate
    [12:36:30] is urlauth ready for wglc? no, there were some comments on the list that haven't yet been resolved
    [12:37:03] plus the "anonymous" issue

    Pull Documents BURL (Chris) 10 min
    [12:37:34] burl: issue: need a rev for reference updates
    [12:37:45] then last call
    [12:38:29] glenn to ted: any issues on urlauth? there has been a draft since his comments were sent
    [12:38:48] glenn will ping mark

    Pull Documents CATENATE (Pete) 5 min
    [12:38:54] pete resnick: catenate
    [12:39:17] needs examples, plus something on what to do with response codes
    [12:40:39] 2119 language? pete says 2119 language isn't necessarily needed
    [12:41:40] randy & chris: need it for interop
    [12:42:56] amelnikov: I agree with Randy & Chris
    [12:45:26] discussion on i18n problems with text
    [12:45:31] chris -- fine as is
    [12:46:12] on to examples: how to deal w/ drafts? other use cases
    [12:46:59] clarification to pete on what examples go in catenate vs. profile doc
    [12:49:49] greg: why do we have catenate at all? don't urlauth and burl cover it?
    [12:51:10] chris: catenate allows you to put copy into sent folder and send it
    [12:51:42] pete: different algorithms if you have annotations, and don't
    [12:52:16] amelnikov: Catenate also allows to strip attachements and edit a draft multiple times
    [12:52:18] chris: forward without download as well as saving file copy
    [12:52:49] greg: two ways to do same thing? bothers him. catenate using burl, vs. bdat, bdat, burl
    [12:53:16] chris/pete: lemonade will require catenate, but not bdat
    [12:53:33] greg: figured bdat WOULD be required
    [12:55:02] chris/randy: yes, there will be more than one way to do the same thing
    [12:55:48] philip g.: another complexity is alexey's draft to request email address for a particular folder
    [12:56:14] michael wener: <<missed it>>
    [12:56:50] pete: wordsmithed document in real time
    [12:58:29] greg: what's preferred way to do fcc? catenate with burl?
    [12:58:33] chris: yes
    [12:59:30] greg: if do future delivery submission, is burl resolved now or then?
    [13:03:16] chris: the URL was resolved before the submit server sends an error response.
    [13:01:27] pete: will go back to editing for next draft
    [13:02:05] pete: call for examples to provide for the doc
    [13:03:04] amelnikov: I can write some examples for Pete
    [13:03:23] send them to pete
    [13:04:24] pete: profile will say: here's how to use catenate to forward w/o download. and that use of annotation would make forward w/o download more efficient, but it is not required by the profile, and may describe how to do so.
    [13:04:51] sub use case of editing drafts can be made more efficient with annotations

    Non-Working Group Items: checkpoint / clearidle (Michael)

    [13:05:22] next: non-work group items
    [13:05:57] michael wener: checkpoint/clearidle
    [13:06:52] goal: provide quasi-real-time reception of server state change; minimize client costs of full sync; minimize protocol changes; obviates RECONNECT, and server-to-client-notifications
    [13:07:53] current drafts don't provide clear description on how to use two together -- need both, and how play together could part of lemonade profile
    [13:08:43] checkpoint: ack'd delivery of imap responses, extends idle, subsumes reconnect
    [13:09:23] resync avoidance: avoid missed events; uses account based queuing
    [13:10:11] defines a 2-session access scenario for imap client; sessions are mutually aware
    [13:10:46] uses imapurl to export uid state between sessions
    [13:11:46] checkpoint: supports both highly connected & lightly connected
    [13:12:23] idle context is a way of scoping both: queue life (queue is self cleaning) & responses w/ new syntax
    [13:13:39] pete: questions where costs of connection are? mike: both tcp level and tls level
    [13:15:27] randy: questions highly vs. lightly connectedness. mike: means how often have active connection
    [13:17:38] clearidle: provide unsolicited responses during IDLE (when in auth state) -- uses IMAPURL used to identify folders & uids -- allows multiple folders to be reviewed covers all state change need to avoid a full sync at reconnect -- all folders, folder state, mail state, expunges
    [13:18:41] the two combined improves mobile mail experience: checkpoing/clearidle: user perceived smoothing of mail reception; msgfilter: focusing on what mail is of interest to user
    [13:19:47] cyrus: can you limit updates to "folders of interest"?
    [13:20:45] mike: it's a problem with no magic wand, can use aggregation -- needs some work
    [13:22:01] discussion genericizing to general server-to-client notification
    [13:22:19] comments about xmpp doing it, reference to jep #60
    [13:23:52] clamor
    [13:25:41] eric: discussion of inband vs. out-of-band models; sip vs. xmpp; imap was not built to do it; we should use the right kind of connection to do notification and not mix it in to imap
    [13:26:34] dave crocker: notification has 2 pieces -- object and transfer -- we need to speicify the objec to be sent and now how it's sent
    [13:27:10] glen: we want reqts of what needs to be transfered from server to client
    [13:27:27] mike: clearidle specifies content
    [13:28:42] greg: still interested specifically in imapish events since last connect or checkpoint

    Non-Working Group Items: msgfilter (Michael)

    [13:29:34] on to msgfilter
    [13:29:58] goal is to constrain what events are seen
    [13:30:15] or, what messages are seen
    [13:30:44] use case #1: mail after a certain date; #2 only mail from *@customer.com
    [13:31:43] some syntax borrowed from old window/view drafts
    [13:32:13] command: FILTER SET; response: FILTER SET; response code: FILTERED
    [13:33:57] transient mode: specify criteria via SEARCH, UID ADD/REMOVE; easy cleanup: self cleaning; filters are definitive
    [13:34:42] non-transient mode: protocol opaque tag
    [13:36:04] filters build dynamically (incrementally); rules have precedence TAG, SEARCH, UID ADD/REMOVE
    [13:37:18] cyrus: window had scalability problems
    [13:37:35] mike: same scalability problems as search command
    [13:39:11] cyrus: serious problems with redefining sequence numbers on the fly
    [13:40:36] mike: burden of maintaining state borne by server, but mitigated by trancience
    [13:43:54] corby: what happens with collected state changes with msgfilter vis-a-vis checkpoint
    [13:44:01] mike: a problem

    Next Steps & Milestones 10 min

    [13:44:13] eric: what's next
    [13:44:46] updated drafts by december 1 (profile, reconnect); wglc for pull trio
    [13:45:13] we're done for the day -- to be continued on wednesday

    NOVEMBER 10 2004

    Slides are at http://flyingfox.snowshore.com/i-d/lemonade/slides61/index.html

    Minutes by Corby Wilson

    Agenda Bashing (Chairs)

    [14:38:16] <corby> welcome to Lemonade
    [14:38:29] <corby> Glen has a new clone. Congratulations!
    [14:38:56] <corby> Agenda bashing
    [14:39:54] <corby> Monday Recap
    [14:40:18] <corby> MMS Mapping, Future Deliv, and S2S are done. Looking for WGLC
    [14:41:02] <corby> URLAUTH: anonymous question on list. Authors will leave it in.
    [14:41:09] <corby> BURL: Done, some nits
    [14:41:21] <corby> CATENATE: Use cases needed (Alexey)
    [14:41:37] <corby> Send URLAUTH, BURL, CATENATE to WGLC by Dec 1
    [14:41:53] <corby> Pete: BURL, nits identified on ML?
    [14:42:04] <corby> Pete: WGLC BURL now.
    [14:42:19] <corby> Is BURL dependent on other 2?
    [14:42:36] <corby> Glenn: Submit all 3 at the same time for WGCL. No need to do individual submission?
    [14:42:48] <corby> Discussion on WGCL process.
    [14:43:26] <corby> CLEARIDLE/CHECKPOINT: vs. Quick Reconnect and S2C.
    [14:43:51] <corby> Is it appropriate in light of other tech: XMPP, SOAP, SIP, etc.
    [14:44:08] <corby> Definitions seem outside of charter, but we can add.
    [14:44:19] <corby> MSGFILTER: Seems similar to XFILTER.
    [14:44:20] <resnick> I need to finish off CATENATE the week of Nov. 22, so I'll need examples by then.
    [14:44:41] <amelnikov> Pete: no problems.
    [14:44:50] <corby> MSGFILTER does not scale in IMAP.
    [14:44:51] <resnick> Thanks Alexey.
    [14:45:02] <corby> Subtle diff btw XFILTER and MSGFILTER.

    Mobile Email (Stephane Maes) http://flyingfox.snowshore.com/i-d/lemonade/slides61/lemonadeChairs61-day2.ppt

    [14:45:12] <corby> Stephane: Mobile email
    [14:45:58] <corby> Purpose is to understand notion of mobile email and should lemonade address the notion of mobile email.

    [14:46:18] <corby> Mobile email: "Access to email while mobile"
    [14:46:34] <corby> Expectation: Receive somewhat-instant notification of email
    [14:46:47] <corby> Efficient manipulation of email
    [14:46:52] <corby> e2e secure
    [14:47:09] <corby> Eric: Anybody surprised by this? (non-goals)
    [14:47:34] <corby> Eric: Notifications can be minutes on the corporate LAN. Immediate notification not necessarily the goal.

    [14:48:36] <corby> Mobile extensions to mail. Full scope to provide mobile email solution including IMAP, SMTP, and all associated tech.

    [14:48:44] <corby> Define quasi-instantaneous delivery
    [14:49:53] <corby> Expect appropriate behavior of email delivery when notifications are enabled.
    [14:50:24] <corby> Additional considerations: Format adaptation (CHANNEL?) DRM rules, Provisioning, Charging (billing), etc.

    [14:50:43] <corby> Pete: All of this is fine, as long as everyone understands that we only work on IP based protocols.
    [14:51:08] <corby> Corby: Sufficient to define a UDP protocol, but not a WAP.
    [14:51:27] <corby> Eric (hat off): Define a msg format and transport (hypothetical).
    [14:51:50] <corby> Mobile world would take GW to SMS or WAP. That's fine, but we won't do it. We will define the GW and interface, but that's it.

    [14:52:11] <corby> This is internet email that supports mobile environments.
    [14:52:40] <corby> Randall: Provisioning, tech already exists (XCAP,etc). Why do we need to redefine for Lemonade.
    [14:52:48] <corby> Eric: is it useful for mail
    [14:53:22] <corby> WGCh: Do Provisioning after everything else has been defined.
    [14:53:47] <corby> Firewall: Are we considering FW and NAT traversal for this?
    [14:53:50] <corby> Stephane: Yes.
    [14:54:43] <corby> Challenges for Consumer and Enterprises;
    [14:55:00] <corby> FW, VPNs, E2E sec, etc. etc. etc.
    [14:55:08] <corby> Deployment Patterns (see slides)
    [14:56:07] <corby> Different deployment models for typical enterprise email setup.
    [14:57:26] <corby> Pete: If you were to circle everything in internet and operator space, everything in that space is not something we are working on?

    [14:57:49] <corby> Is Mobile e-mail enabling server etc. in the domain of IP?
    [14:58:01] <corby> Is the connector the edge of IP?
    [14:58:16] <corby> Pete; Connector is not an IP protocol entity.
    [14:58:34] <corby> Greg: Connector can be an IMAP proxy.
    [14:58:44] <corby> Connector is a logical drawing and may not necessarily exists
    [14:59:20] <corby> In fact, the goal of the WG is the line from the email client to the email server.
    [14:59:43] <corby> There may be other servers, proxies, GW in between, but these are out of the scope of the WG.
    [15:00:14] <corby> What is the scope of Lemonade?
    [15:00:28] <corby> Greg: Wants all of these issues addressed (many).
    [15:00:51] <corby> Greg: The competition is extreme and they handle all of the scenarios, so if we don't why are we here?

    [15:01:14] <corby> Greg: All current email is either proprietary or proprietary derivatives of existing standards.
    [15:01:49] <corby> Stephane: Argument can be made to do E2E in IMAP, but reality is we will require other servers to mobilize across networks and vendor spaces.

    [15:02:18] <corby> (cont) Do we want to create something that can compete in the space or do we want to improve what we have?

    [15:03:05] <corby> We will not contort protocols to work around implementation deficiencies in the TCP/IP stack infra in mobile networks and devices.

    [15:03:18] <corby> Don't fix IP problems in the phones.
    [15:03:52] <corby> Eric: Timeline is next year. Most likely the phones will be fixed by the time we release Lemonade.
    [15:04:31] <corby> Eric: Apr 2004, BLOAT was proposed which would solve all these issues. Not considered for this, but just an example

    [15:05:18] <corby> S: Understanding that we can not keep a TCP connection up all the time, we can't fix that and we shouldn't try to fix that, but we can account for characteristics of the network.
    [15:05:19] <Glenn Parsons> FYI, the web slides are on the LEMONADE supplemental site
    [15:05:23] <corby> Eric: We are going to be idealistic and practical.
    [15:06:18] <corby> Randy: If we have solutions which are useful for general classes of problems, then we can support more.

    Lemonade Goals (Kue Wong) http://flyingfox.snowshore.com/i-d/lemonade/slides61/Goals_-_IETF_61_comments_KW.ppt

    [15:06:33] <corby> Presentation of Lemonade Goals:
    [15:06:50] <corby> Comments were useful and were incorporated into the draft.
    [15:07:08] <corby> All editorial nits accepted.
    [15:07:51] <corby> the goals document was not intended as a working requirements document, but rather as a historical record.

    [15:08:54] <corby> Eric: we are not going to replace IMAP, (IMAP-NG).
    [15:09:22] <corby> Eric: We are extending IMAP not writing replacement commands or protocols.
    [15:09:28] <corby> No such thing as a Lemonade protocol.
    [15:10:24] <corby> Discussion on Goals references. NP
    [15:11:21] <corby> Fix phrasing in current Goals doc
    [15:12:11] <corby> Q: Is the intion of MMS mapping to define MMS as the primary transport of Lemonade in mobile net?
    [15:13:45] <corby> Randy: Mapping work hits charter item. If you have MMS system and a separate mail system, then those systems can interoperate. There is no dependency in Lemonade to MMS.

    [15:13:55] <corby> Randy: Simply and inter-working document.
    [15:14:29] <corby> Eric: Pragmatic approach to interworking protocols.
    [15:15:24] <corby> Randy: First step to replacing MMS or custom protocols with IP protocols to get homogeneous network system over mobile nets

    [15:17:30] <corby> Reminder: Slide sets available on Alternate Lemonade Page: http://flyingfox.snowshore.com/i-d/lemonade/

    [15:17:58] <corby> Glenn: We are not creating a new IMAP, we are not creating a new internet email. We are simply defining extensions.

    [15:18:40] <corby> Stephane: Needed to understand the goal of the Goals document.
    [15:18:53] <corby> Q&A: none
    [15:19:17] <corby> Eric: Mumbling: All changes are editorial in nature, so WGLC is closed.
    [15:19:28] <corby> No objections given. Update doc and send to AD ASAP.
    [15:20:06] <corby> Stephane: Goal2 item. Will have some time to discuss progress resolution?
    [15:20:16] <corby> Glenn: Will discuss at end of meeting.

    Lemonade Profile (Stephane Maes) http://flyingfox.snowshore.com/i-d/lemonade/slides61/lemonadeChairs61-day2.ppt

    [15:20:34] <corby> -----------------------------------
    [15:20:40] <corby> Stephane: Presenting Lemonade Profile
    [15:20:53] <corby> What should be done with profile.
    [15:21:20] <corby> Add the current drafts into profile content.
    [15:21:51] <corby> Glenn: WGCL on profile, decide if we want profile1 and go to new profile or hold profile and continue to update profile and make it a living doc.

    [15:22:16] <corby> Have profile1 be a living doc and continue update and limit to current drafts.
    [15:22:35] <corby> have revision on profile in the next 2 weeks for submission.
    [15:25:39] <Glenn Parsons> Note that the Stephane's slides on mobile email are in the directory for the 60.5 interim meeting

    Quick Reconnect (Corby Wilson) (slides not yet on web site (Eric: fix))

    [15:22:49] <corby> --------------------------
    [15:23:09] <corby> Someone channel Alexey if he as a question or statement.
    [15:25:54] <Glenn Parsons> Corby presenting
    [15:26:56] <Glenn Parsons> indicates that some study is still needed on Michael Wenner's proposal
    [15:27:19] <randy> New SID/NEWSID param on LOGIN/AUTHENTICATE
    [15:27:28] <randy> Creates resumable session. Can keep on LOGOUT.
    [15:27:35] <randy> Send EXPUNGEs
    [15:27:54] <randy> Send FLAGs
    [15:28:25] <randy> Corby goes through states
    [15:31:44] <randy> Open issues:
    [15:32:08] <randy> - server-side state cache (can we eliminate this and have client send enough information)
    [15:32:26] <randy> - number of sessions per account
    [15:32:26] <pguenther> clarification that loss of SID may require resync of dynamic info (uidlist, flags) but unless the UID validity changes it doesn't require resync of static info

    [15:32:27] <randy> - timeout
    [15:32:30] <randy> - condstore
    [15:35:19] <randy> Cyrus points out that currently clients can reconnect without blocking while resynch
    [15:35:28] <amelnikov> The CONDSTORE issue: RECONNECT extends LOGIN to report EXPUNGEs, do we want to do the same to SELECT (i.e. extend CONDSTORE a bit)

    [15:35:32] <randy> Cyrus suggests bandwidth reduction is a worthwhile goal
    [15:36:58] <amelnikov> The timeout issue: what should be the default? Should the server be able to advertise its session expiration timeout?

    [15:38:08] <randy> Discussion of implicit checkpoints: how does server know which responses client has received
    [15:39:30] <randy> Cyrus asks why we need SID if we already require CONDSTORE; client can use CONDSTORE to request changes

    [15:41:21] <amelnikov> The currently opened mailbox is bound to the SID
    [15:41:43] <randy> Alexey: what is that in response to?
    [15:42:04] <amelnikov> In response to the last question from Cyrus
    [15:42:40] <randy> So it just saves SELECT?
    [15:42:47] <amelnikov> Yes
    [15:43:57] <amelnikov> Maybe we can replace SID with mailbox name. But I have to check that nothing else is going to be lost after this change.
    [15:45:06] <randy> Randy notes that if SID only buys you ability to avoid SELECT if you get lucky and reconnect within timeout, then why not come up with another mechanism that allows you to avoid SELECT at all times, so it benefits clients that reconnect 3x week as well as those that happened to get dropped.
    [15:45:07] <pguenther> the expunge information may be, but if that is done as an extension to condstore...
    [15:46:28] <randy> Eric suggests this is a service provider choice (how much resources to spend and hence how long timeouts are permitted)
    [15:46:29] <amelnikov> Currently the assumption is that the current mailbox state is associated with SID, so on reconnect some responses don't have to be sent to the client.
    [15:47:32] <randy> Ted suggests loss of connectivity is more compelling problem than reconnect 3x week, notes that LDAP has similar problems
    [15:48:10] <randy> Alexey: I thought there was discussion on adding this to CONDSTORE?
    [15:48:16] <randy> So only CONDSTORE was needed?
    [15:48:39] <randy> Chris would like to do without SID if possible, adds more complexity
    [15:48:40] <amelnikov> Randy: adding what to CONDSTORE?
    [15:49:03] <randy> Alexey: adding extra responses that aren't there now
    [15:49:36] <amelnikov> RECONNECT also combines LOGIN with SELECT
    [15:49:39] <randy> Chris suggests that are approaches that would avoid round-trips by adding atomicity to reconnect
    [15:50:32] <randy> Alexey: right, so if we add the extra responses to CONDSTORE, all that RECONNECT gives you is ability to avoid SELECT, and we can have a mechanism for just that
    [15:51:41] <randy> Chris suggests that today very few clients use PIPELINING, and suggests one reason is the problem that an early command fails but subsequent ones run anyway, atomicity allows sequence to abort
    [15:52:00] <amelnikov> Randy: maybe. Something is still bothering me about state of the selected mailbox. But I can't say what yet
    [15:52:19] <randy> Corby sais big problem is too much information coming back, much of it redundant
    [15:52:31] <amelnikov> I've heard that Apple mail uses PIPELINING
    [15:53:19] <pguenther> Corby mentioned Thunderbird does too?
    [15:55:31] <randy> Cyrus to look at Alexey's document to see about adding advice on how not to be a stupid client
    [15:56:00] <randy> Draft is 'draft-melnikov-imap-disc-05.txt'
    [15:56:30] <amelnikov> Actually -06 now

    CHANNEL (Eric Burger) (no slides)

    [15:56:41] <corby> -------------------
    [15:56:43] <corby> Take over
    [15:56:47] <corby> TRANSCODING
    [15:57:29] <corby> See email from Lydon on Transcoding (WED 11.10.2003)
    [15:57:34] <pguenther> if condstore is extended to do expunge bits, it may be wise to include a section describing how it affects the IMAP-DISC discussion

    [15:58:07] <corby> Add MIME type to CHANNELCONVERSION to indiciate capabilities.
    [15:58:32] <corby> Use channel command to do a particular transformation from (a) to (b)
    [15:59:10] <corby> Eric: Recap Vancouver discussion on transcoding.
    [15:59:26] <corby> IMAP server asks for the conversion to be done.
    [16:00:09] <corby> Phillip: Use URLAUTH to convert.
    [16:01:08] <corby> If it's a streaming event use URLAUTH. On normal objects and attachments we had just normal IMAP FETCH

    [16:01:29] <corby> Some of these formats take many many parameters (eg, video).
    [16:01:54] <corby> Eric: Mime type is not sufficient to do the conversion because more parameters are needed to do proper transformation.

    [16:02:15] <corby> Eric; Is this the way we want to go?
    [16:02:46] <corby> Gregg: Is this the consesus on view of streaming retrieval for case A. Use IMAP or RTSP?
    [16:03:38] <corby> What about S/MIME and resigning.
    [16:03:46] <corby> Was discussed in Vancouver.
    [16:04:03] <corby> Eric: Not solvable for enc/dec. But for signing what do we need?
    [16:04:14] <corby> What is on the server, stays on the server.
    [16:04:33] <corby> Server content never changes, but what you fetch may change and may loose it's signature/
    [16:04:44] <corby> Yes, that may happen
    [16:05:08] <corby> They may or may not now that the content has changed, but they know that it isn't signed.
    [16:05:53] <corby> remove the signature as content is transformed, or leave the sig and leave it broken.
    [16:06:11] <corby> Transform the signed part into a hash?
    [16:06:48] <corby> 822 discussion on signing individual parts and then hashing the tree to confirm individual singed parts.

    [16:07:33] <corby> Use contenttype "multipart/alternative"?
    [16:08:09] <corby> Is there a way to verify the signature with out downloading the entire message.
    [16:08:31] <corby> What is the usecase for transcoding?
    [16:09:09] <corby> Client device can not handle original content of attachment. Client asks server to translate type into something the terminal can display.

    [16:09:38] <corby> Signing is something we need to be aware of, but not something we need to solve here.
    [16:10:10] <corby> ERIC: We need a new "Stupid Things" Draft for lemonade to add nits like this to make people aware that we thought about it.

    [16:10:48] <amelnikov> To Eric: maybe this is a part of Lemonade profile?
    [16:11:09] <corby> Isd this a general IMAP problem? Or do other email servers have to deal with this??
    [16:11:37] <corby> Side Note: Please review OPES re-charter. It is relevant to the work we are doing here and everyone needs to be aware of this

    [16:12:17] <corby> OPES protocol may simplify this problem by using OPES server to resign body/mime parts.
    [16:13:23] <corby> Randy: Confirm consensus. For the class of content where the content doesn't need to be streamed, client asks server to FETCH and transcode it, second, client connects to separate server with URLAUTH and asks transform server to do the work for it.
    [16:13:44] <corby> Eric: All we care about is how to hack FETCH to do transcoding.
    [16:14:08] <corby> Randy: Usefull for informational note to say: OPES may be useful approach to solving this problem.
    [16:14:31] <corby> Send Signing to IMAP-EXT and let them deal with it :)
    [16:14:52] <corby> Pete: Fine to pass over to IMAP-EXT, but they may ask use to work on it.
    [16:14:58] <corby> Do we want to Punt?
    [16:15:04] <amelnikov> Corby: if you want to delay something for long time, that is a sure way :-)
    [16:16:16] <corby> Stephane: Develop CHANNEL document w/o signature problem now so we can move on this for now and deal with edge cases later.
    [16:16:47] <pguenther> (punt should be to S/MIME)

    Message Filtering (WG Chairs)

    [16:16:23] <corby> -----------------
    [16:16:28] <corby> Filter Discussion
    [16:17:34] <corby> Stephane: Third option: Decide in advance when a new message arrives, choose what is being downloaded.
    [16:18:14] <corby> Use SIEVE to filter at the MTA.
    [16:18:52] <corby> PG: Changing the rules of what appears on your mobile can't be done quickly, and is difficult to make retroactive.
    [16:19:23] <corby> Pete: Chage SIVE rule to re-annotate the new stuff and re-annotate the current mail to take care or retroactive.
    [16:19:37] <randy> Sieve can be used to (a) forward selected messages to mobile, (b) move class of messages out of INBOX and only SELECT that folder, (c) use ANNOTATE to add annotation, mobile device does SEARCh and only selects items with annotation
    [16:20:17] <corby> PG: I'm getting trafic for messages I don't care about. Is this important when terminal gets woken up for trafic I dont want to see
    [16:21:41] <corby> 2 approaches. Filter to new mailboxes or filter on views.
    [16:21:54] <corby> Eric: Rathole we have entered before.
    [16:22:31] <corby> XFILTER is view mech of SQL.
    [16:23:08] <corby> You rmobile rules are relativey static, and even if they do change you don't care about history (retroactgive behaviour)
    [16:24:18] <corby> Is the usecase that you have strong filters that you have for the device and you want to change dynamically.
    [16:25:06] <corby> Unless we have an argument for retroactive functionality, it will not be added to the charter.
    [16:25:36] <corby> Coherent proposal for quick reconnect stratgegy
    [16:25:48] <corby> Added to charter, more discussions needed on ML

    Admin (WG Chairs) http://flyingfox.snowshore.com/i-d/lemonade/slides61/lemonadeChairs61-day2.ppt

    [16:25:51] <corby> -------
    [16:25:53] <corby> TIMELINE
    [16:26:00] <corby> Dec1: Profile
    [16:26:07] <corby> WGLC: Pull trio
    [16:26:18] <corby> New Docs: S2C Notifications, Transcoding
    [16:26:28] <corby> ----------
    [16:26:35] <corby> Interim?
    [16:26:40] <corby> Quick Reconnect Options
    [16:26:54] <corby> transcoding requirements
    [16:27:43] <corby> transcoding approaches
    [16:28:17] <corby> Interim: Jan 21-22, 2005 (afternoon-morning)
    [16:28:26] <corby> Host (def, Nortel-Calgary)
    [16:30:11] <corby> Screwup: Jan 20-21, 2005 (Thurs & Friday)
    [16:32:36] <corby> THANK YOU AND GOOD NIGHT!


    Future Delivery: WGLC Comments
    MMS/Email Mapping
    Chair slides - Day 2
    Chair slides - Day 1
    Goals: WGLC
    Lemonade Requirements for Server to Client Notifications