Subject: [lemonade] Draft Meeting Minutes for Wednesday

From: [email-masked]
Date: Fri, 12 Nov 2004 15:04:49 -0600

Here are the logs.

-----------------------------------------------------------

[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-da
y2.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_com
ments_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-da
y2.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-da
y2.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!

Corby Wilson
Security, Connectivity & Mobillity
NOKIA
503 Martindale Street
Suite 610
Pittsburgh, PA 15212
+1.412.320.2068 (w)
+1.412.320.2080 (f)
+1.412.576.5402 (m)
[email-masked] 

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade