Last Modified: 2004-11-01
|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|
LEMONADE WG IETF-61 NOVEMBER 8, 2004
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)
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: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!