[08:46:37] --- kmurchison has joined
[08:46:45] --- kmurchison has left
[08:46:52] --- kmurchison has joined
[08:47:30] --- kmurchison has left
[11:19:29] --- eburger has joined
[11:19:46] <eburger> test
[11:20:16] --- eburger has left
[11:21:06] --- eburger has joined
[11:21:18] --- eburger has left
[12:35:59] --- kmurchison has joined
[12:36:19] --- kmurchison has left
[12:40:50] --- MRCrispin has joined
[12:41:46] <MRCrispin> test test
[17:22:05] --- rjs3 has joined
[17:22:21] --- rjs3 has left
[17:38:48] --- Daniel has joined
[17:38:58] --- Daniel has left
[17:43:37] --- kmurchison has joined
[17:44:17] --- NFreed has joined
[17:44:36] --- cnewman has joined
[17:44:57] <NFreed> So it is only offsite people in the room so far?:
[17:46:06] <MRCrispin> Alexey says that he was asked to present the URLAUTH and PULL drafts.
[17:47:28] --- warlord has joined
[17:49:38] --- eburger has joined
[17:49:56] <eburger> I'
[17:49:58] <eburger> m here
[17:50:20] <eburger> It looks like I will be your humble Jabber scribe, unless I can find someone else to do the transcribing...
[17:50:41] <eburger> That does mean we don't have to wait in line for the Mic :-)
[17:51:20] --- tonyhansen has joined
[17:52:13] <tonyhansen> I'll tag team with you as jabber scribe (filling in any blanks you miss)
[17:53:35] <cnewman> Maybe we should just get two people with Nerf bats at the front of the room to determine push vs. pull?
[17:53:44] --- ludomp has joined
[17:53:44] <eburger> :-)
[17:54:06] <eburger> We were thinking more like 20 Paces ...
[17:54:39] <eburger> Do we have a media feed?
[17:54:42] <eburger> (other than text)
[17:55:04] --- Glenn Parsons has joined
[17:55:20] <cnewman> I'm sitting with Ned, and he has an iSight. We were hoping Pete Resnick would iChat with us...
[17:55:24] --- kdz has joined
[17:55:39] <MRCrispin> I have a multicast here, but it cuts out every 10-15 minutes.
[17:56:23] <warlord> but it comes back, right?
[17:56:34] <Glenn Parsons> I can switch to Panther, but I don't have a camera...
[17:56:47] <Glenn Parsons> Mr. Resnick is not int he room yet...
[17:57:10] <MRCrispin> I've been clicking the pause/play button to make it come back.
[17:57:14] <NFreed> Don't need Panther, actually; there's a version of iChat AV that runs on Jaguar.
[17:57:16] <eburger> Glenn just got a camera from Edwin.
[17:57:34] <Glenn Parsons> Just got an iSight, will now check if it works with my Pismo...
[17:58:16] <eburger> Pete will take care of iSight...
[17:58:29] <Glenn Parsons> Pete has now arrived!!!
[18:00:01] --- alexeymelnikov has joined
[18:00:51] --- randy_g has joined
[18:01:29] <eburger> Alexy's slides have been posted to the web page
[18:02:02] --- resnick has joined
[18:02:40] --- Hippasus has joined
[18:03:00] <Hippasus> (Hippasus is jwn2 in disguise
[18:03:22] <alexeymelnikov> Slides can hardly be called slides. They are "extracts"
[18:03:36] <MRCrispin> the multicast just cut out again and it's not coming back
[18:04:03] <warlord> it's a conspiracy to make sure you can't see what's going on..
[18:04:26] <MRCrispin> now I have video but no audio...
[18:04:35] <eburger> Mark -- did you get a SIP client?
[18:04:56] <MRCrispin> no
[18:04:59] --- Hippasus has left
[18:05:27] <MRCrispin> multicast is back again. this is going to be "fun" :-(
[18:05:48] --- nsb has joined
[18:06:36] --- Lisa D has joined
[18:06:37] <eburger> Is everyone having the multicast problems?
[18:06:43] --- BP has joined
[18:07:07] --- Hippasus has joined
[18:07:29] --- rlbob has joined
[18:07:37] <Hippasus> Ned, what's your AIM handle?
[18:08:04] <tonyhansen> bashing agenda
[18:09:43] --- galvinjamesm has joined
[18:10:18] <MRCrispin> multicast cut out again
[18:10:46] <tonyhansen> btw, eric sent this to the list: Drafts, etc. are still at http://flyingfox.snowshore.com/i-d/lemonade/ Meeting slides, agenda, etc. are at http://flyingfox.snowshore.com/i-d/lemonade/slides59/index.html
[18:10:53] <randy_g> Glen: we hope to come to a decision on ush vs pull soon
[18:11:24] <randy_g> Glenn: we may try again for a push vs pull conference call; we'll discuss this at the end of the mtg
[18:11:35] <eburger> Comments on agenda?
[18:11:52] <tonyhansen> going over charter...
[18:12:37] <tonyhansen> 1) lemonade goals 2) imap4 ext for vm playback 3) imap4 ext for forwarding 4) imap4 profile for diverse endpoints 5) s2s notification 6) translation to/from other msging systems
[18:13:12] <tonyhansen> question: should we be working on a generic composition protocol?
[18:13:14] <randy_g> Glenn asks if anyone thinks we should extend charter to work on generic comp protocol?
[18:13:23] <cnewman> The charter explicitly permits both imap4 ext and smtp ext, but no other protocols.
[18:13:40] <tonyhansen> randy: can we update 3rd bullet because it presumes a solution
[18:14:21] <randy_g> 3d bullet updated to "IMAp4/Submit" to match charter
[18:14:45] <randy_g> No one spoke in support of extending charter to do generic composition
[18:15:13] --- hardie has joined
[18:15:14] <eburger> we're on slide 6 now
[18:15:17] <tonyhansen> chair: doc status
[18:15:42] <alexeymelnikov> I am a bit confused: So is CATANATE in the charter or outside the charter?
[18:16:27] <tonyhansen> chair:catenate is one of pieces of push/pull, so part of charter
[18:16:40] <MRCrispin> I don't think that anyone has strong objections to CATENATE.
[18:16:42] <randy_g> (Reply to Chris: actually, charter refers to message submission, not SMTP)
[18:17:22] <tonyhansen> chair: any ?s on goals doc?
[18:17:36] <tonyhansen> none
[18:18:17] <tonyhansen> randy: can we verify that goals is just going to WG last call?
[18:18:25] <tonyhansen> chair: 1 more rev for nits, then WG last call
[18:19:38] <tonyhansen> channel: is it ok to : hold this until pull/push resolved? no objections
[18:19:50] <hardie> Is that a beer your drinking, ned/
[18:19:54] <hardie> ?
[18:20:01] <hardie> I'm jealous....
[18:20:07] <tonyhansen> chair: mms mapping: can we also hold this until pull/push?
[18:20:57] <tonyhansen> gregv: hold for imap profile doc as well
[18:22:02] <NFreed> No beer, just tea. Alas.
[18:22:03] <tonyhansen> randy: not really a dependency, but more just not to split our attentions too many ways
[18:24:12] --- Hippasus has left: Replaced by new connection
[18:24:28] --- Hippasus has joined
[18:24:31] <randy_g> Current mms mappings doc has normative ref to future delivery; update changes this to descriptive ref since mapping doc is for relay, and future delivery is for submission
[18:24:44] <tonyhansen> chair: server-to-server notificcations reqts doc: ok to do nits review, then WG last call? yes
[18:25:09] <tonyhansen> chair: media size? not a wg doc, so proceed it to ad review
[18:25:35] <tonyhansen> chair: greg is waiting on futuredelivery until after push/pull
[18:25:37] <eburger> Ned: any comments on media size?
[18:25:51] <tonyhansen> alexy @mike: ned had comments
[18:26:03] <NFreed> Yes, but I haven't had time to finish them up and send them on.
[18:26:08] <randy_g> (clarification that mms mapping doc action by group will wait for push vs pull decision, but not completion of push vs pull)
[18:26:14] <NFreed> Mostly nits, I believe.
[18:26:44] <cnewman> I read the media size spec and sent back several pages of comments, some of which were fixed in -04. But I dropped the ball after that because I got swamped at work.
[18:27:16] <NFreed> Chris and I are in the same boar there...
[18:27:56] <tonyhansen> greg: should future delivery include revocation? may have impact on other discussions
[18:27:59] <hardie> ow
[18:28:03] --- jean has joined
[18:29:04] <tonyhansen> chair: sending this question to the list
[18:29:18] <cnewman> To revoke future delivery properly gets into some of the same nasty security issues that the intersection of forward without download and multipart/signed get into... It's a lot of work, can be solved, but would be very distracting to push vs. pull.
[18:30:09] <tonyhansen> randy: should we even look at this? or is it an absolute requirement that would dictate something with push/pull?
[18:30:27] <tonyhansen> chair: take it to the list
[18:30:43] <tonyhansen> greg: is this not a reqt, a soft reqt, a hard reqt?
[18:31:19] <tonyhansen> pete: reading chris' comment on revocation
[18:31:37] <tonyhansen> chair: hum: should we NOT be looking at revocation at all?
[18:31:44] <tonyhansen> no one hummed
[18:31:58] <tonyhansen> chair: is revocation a hard reqt? small support
[18:32:09] <MRCrispin> hum on "nice to have"
[18:32:14] <tonyhansen> chair: is it a "nice to have"?
[18:32:29] <tonyhansen> alexy: this could be dealt with in a different doc
[18:32:31] <hardie> I think Greg's concern is that it might be easier to acccomplish with one over the other, knowing whether it is a req. no
[18:32:42] <hardie> s/no/now
[18:32:45] <hardie> would be useful.
[18:32:55] <hardie> Looking like "soft requirement"--nice to have
[18:32:58] <tonyhansen> alexy: can revocation be an extension to future deliv?
[18:32:59] <hardie> is the sense of the room
[18:33:05] <randy_g> Alexey suggests splitting revocation into extension to future delivery.
[18:33:18] <tonyhansen> moving on
[18:33:26] <tonyhansen> to push/pull
[18:33:43] --- smaes has joined
[18:34:16] --- Milkshake has joined
[18:34:24] <tonyhansen> going over history of push/pull
[18:34:24] <randy_g> Glenn gives status update on push vs pull
[18:34:51] <tonyhansen> chair: we have the docs to make a discussion
[18:34:51] <randy_g> Glenn: we want to pick one direction, and we now have enough details to decide
[18:35:14] <randy_g> Chair: we have external realities that are driving our schedule:
[18:35:21] <tonyhansen> chair: marketplace realities
[18:35:38] <randy_g> MM1 is real and widely deployed (longer we take the harder it will be for our work to be accepted)
[18:36:19] <tonyhansen> we need a direction now -- mm1 is starting to be deployed
[18:36:24] <alexeymelnikov> I have a concern that if we rush and make a wrong choice, nobody will end up implementing anything
[18:36:25] <randy_g> chair: we are seeing major MMS deployments this year
[18:36:46] <randy_g> Chair: we need to be compelling over MM1 or MM1 will be used
[18:37:16] <tonyhansen> chair: if we aren't a compelling choice over mm1, imap/pop will become irrelevant
[18:37:34] <tonyhansen> randy: the mm1 being referred to is wap/mm1
[18:37:46] <hardie> wap/http mm1, I believe he said
[18:37:59] <tonyhansen> chair: the longer we talk about, fewer will care
[18:38:19] <randy_g> chair: wireless devices will be the bulk of messaging apps, so if we are not compelling, POP/IMAP will fade away
[18:38:27] <tonyhansen> chair: push/pull issues
[18:38:28] <alexeymelnikov> What about pilot implementations of both pull and/or push?
[18:38:54] <cnewman> Slide is not accurate -- CATENATE provides an FCC solution for Pull.
[18:38:54] <tonyhansen> 1) 3rd party trust 2) fcc 3) future delivery
[18:38:54] <hardie> That increases the risk the chairs are discussing
[18:39:12] <hardie> (last comment re: pilots)
[18:39:33] <tonyhansen> push: 1) imap complexity 2) reduce deployment flex 3) submit features need to track esmtp 4) how to handle dsn's
[18:40:13] <tonyhansen> alexy: fcc is not a diff between push/pull, cause all three proposals have way to do fcc
[18:40:54] <tonyhansen> randy: wants to second timeliness as being really-really important, we have the info, and can make the decision
[18:41:08] <alexeymelnikov> CATANATE is also being use by PUSH
[18:41:12] <tonyhansen> randy: we're sort of coming to a consensus on the list and can wrap this up
[18:41:28] <tonyhansen> randy: there are good reasons for both, and bad problems for both
[18:42:14] <tonyhansen> chair: note: randy will be editor of doc for the "chosen method"
[18:42:24] <tonyhansen> on to discussion of pull series of docs
[18:42:40] <tonyhansen> alexey on pull
[18:43:02] <tonyhansen> slides are on web site
[18:44:11] <randy_g> Alexey gives overview of pull
[18:45:37] <randy_g> Alexey: message composition, message assembly, message submission
[18:46:05] <randy_g> Alexey: currently assembly and submission are done as single step when client connects to submit server
[18:46:23] --- Lisa D has left: Disconnected
[18:47:16] <randy_g> Alexey: one pull varient (BURL) combines message assembly and submission on submit server
[18:47:35] <randy_g> Alexey: this leaves fully constructed message on IMAP server
[18:48:03] <randy_g> Alexey: this *doesn't* leave fully constructed message on IMAP server
[18:48:16] <randy_g> Alexey: second varient uses BURL and CATENATE
[18:48:19] <tonyhansen> (greg: slide was wrong)
[18:49:05] <randy_g> Alexey: message is assembled on IMAP server, then submitted to submit server
[18:49:33] <randy_g> Alexey: this approach makes the submit server's job very easy
[18:50:17] <randy_g> Alexey: third varient is BURL with embedded external references. This doesn't need CATENATE. Client uses APPEND for message, then submits with BURL.
[18:50:51] <randy_g> Alexey: this is draft friendly, because client can download draft for edits without downloading external data
[18:51:12] <MRCrispin> answer to pete: draft-friendly for the client
[18:51:12] <tonyhansen> pete: when we talk about draft friendly, does that mean for the server or for the client?
[18:51:17] <tonyhansen> alexey: for the client
[18:51:29] <tonyhansen> gregv: what's diff between embedded uri and catenate
[18:51:49] <tonyhansen> alexey: catenate assembles it at the moment(?)
[18:52:29] <tonyhansen> pete: when you amnipulate the msg, you get it all, whereas #3 only get the framework w/o the parts
[18:52:51] <tonyhansen> gregv: is #3 going to get a single url?
[18:53:10] <tonyhansen> alexey: yes
[18:53:21] <tonyhansen> gregv: so urls will be the signed url certificates?
[18:53:24] <randy_g> Greg: with third variant submit server needs to do multiple fetches
[18:53:25] <tonyhansen> alexey: yes
[18:53:45] <randy_g> Alexey: URLFETCH allows multiple bodies parts to be fetched with single command
[18:54:37] <randy_g> Alexey: so if the various parts are all on one server, there will be at most two fetches
[18:54:39] <tonyhansen> greg: which of the three is the leading contender?
[18:54:55] <tonyhansen> alexey: can we show hands?
[18:54:58] --- mwener has joined
[18:55:06] <cnewman> I support deploying (1) quickly, then deploying (2) as an upgrade.
[18:55:07] <tonyhansen> chair: is their a pref in the pull community?
[18:55:17] <tonyhansen> randy: #1 is subset of #2
[18:56:05] <tonyhansen> randy: so really a choice of 1+2 together and 3
[18:56:24] <cnewman> I'm not particularly fond of (3), but it's much better than push.
[18:56:39] <tonyhansen> greg: is there a #4?
[18:57:07] <tonyhansen> greg: 2 retrieval mechanisms, one that uses imap and the other that doesn't? one used for drafts, and the other for submission?
[18:57:58] --- Milkshake has left
[18:58:44] <tonyhansen> (people trying to clarify who does what in each variant)
[19:00:00] --- rjs3 has joined
[19:00:54] <tonyhansen> ted: there is a signficant diff btw in kinds of tradeoffs if assembly is always being done in 1 place (in imap svr) or 2 places
[19:01:09] <MRCrispin> The three Pull variants were created to fit different sets of requirements...it would not be excessively difficult to tweak these variants if there is concensus on a particular requirement.
[19:01:17] <tonyhansen> ted: we should poll for who should do the assembly first?
[19:01:45] <cnewman> For security reasons, it's important to keep the IMAP server "siloed" so assembly on the IMAP server is only appropriate when assembling parts from the IMAP server. Assembly from arbitrary locations has to occur on the submit server.
[19:02:09] <tonyhansen> ted: who's the AD? Ned or me?
[19:02:22] <tonyhansen> ned (via pete) I don't care
[19:02:54] <tonyhansen> greg: comment on where assembly occurs: would like to do signing, which requires access to private key, but feels like should be closer to imap server
[19:03:24] <NFreed> The thing that's needed at this point is a detailed security analysis of both
[19:03:25] <NFreed> proposals.
[19:03:29] <randy_g> Pete: to deal with drafts problem, a varient of #2 is that client would upload/download skeleton, then use CATENATE
[19:03:42] <NFreed> There have been a lot of opinions thrown around regarding this.
[19:04:02] <NFreed> Unfortunately most of them aren't based on real analsysis and hence are
[19:04:05] <randy_g> Pete: this keeps only skeleton draft on server until last step
[19:04:08] <NFreed> seriously lacking.
[19:04:22] <randy_g> Pete: disadvantage is extra download/upload at end
[19:04:27] <NFreed> Chris and I started work on such an analysis a few days ago.
[19:04:34] <NFreed> Hopefully we'll be able to publish it soon.
[19:05:33] <randy_g> Alexey: with pull there is only one submission protocol
[19:06:01] <eburger> Ned: any idea when?
[19:06:05] <randy_g> Alexey: pull is more flexible in allowing authentication strategies
[19:06:13] --- galvinjamesm has left: Disconnected
[19:06:41] <randy_g> Alexey: also pull avoids adding submission complexity and extensions to IMAP [[ not sure I got this right ]]
[19:06:47] <NFreed> We have the outline and intro but need to work on substance.
[19:06:56] <NFreed> RIght now it is basically a set of bullet items.
[19:07:05] <randy_g> Greg: we don't need to restrict push to selected mailbox only
[19:07:39] <randy_g> Pete: Chris pointed out difficulties with state changes, not sure if also applies to URLFETCH
[19:07:51] --- galvinjamesm has joined
[19:07:59] <tonyhansen> greg: restrciton doesn't apply here
[19:08:42] <MRCrispin> What I was talking about was shared mailbox on a different server
[19:08:57] <tonyhansen> on to push, pete @mike
[19:09:10] <randy_g> Greg: restriction shouldn't apply to push if it doesn't apply to URLFETCH
[19:09:21] <tonyhansen> pete: 3 areas of concern driving him to push
[19:09:37] <tonyhansen> pete: 1) implemtability questions vs. what's going to get done anyway
[19:10:00] <randy_g> Pete: people will implement push no matter what we do because they think it is easier
[19:10:11] <randy_g> Pete: and they might make a mess of it
[19:10:19] <randy_g> Pete: so we need to do push, and do it right
[19:10:37] <tonyhansen> pete: will pull be easy enough to understand so people are willing to implement it?
[19:10:55] <tonyhansen> pete: so is push an okay thing to do?
[19:11:08] <tonyhansen> pete: 2nd concern) security aspects
[19:11:13] <randy_g> Pete: not convinced he understand security implications of pull
[19:11:33] <tonyhansen> pete: thinks he understands security of push, but not fully for pull
[19:11:41] <randy_g> Pete: he understands at least some security concerns of push and deployment strategiies to deal with them
[19:11:42] <tonyhansen> pete: pawn ticket security?
[19:11:43] <cnewman> Push has some _very_ complex security issues, just as complex as pull.
[19:12:34] <cnewman> Proxies are the most common cause of security problems and interoperability problems in SMTP. Push is a proxy and appears deceptively simple, but actually has really nasty security issues.
[19:12:45] <tonyhansen> chair: a security review was sent to list a few minutes ago
[19:12:58] <randy_g> (to Ned and Chris: if you need help with the draft let me know)
[19:13:14] <NFreed> Thanks, Randy.
[19:13:31] <tonyhansen> pete: 3rd concern) what are the architectural problems with push vs. pull?
[19:14:33] <tonyhansen> pete: regarding alexey's comment about tracking changes, push gives everything to server, so possible to not track diff extensions in the future
[19:15:04] <tonyhansen> alexey: annotate is one huge chunk of work that he doesn't feel implementors are doing and will delay push
[19:15:23] <tonyhansen> randy: reading chris's comment on push's security issues
[19:15:42] <tonyhansen> chair: one of nasty security issues is authenticating sender
[19:16:08] <tonyhansen> chair: (this was a comment from ned, evidently)
[19:16:14] <randy_g> Derek Atkind: I'm a security guy
[19:16:27] <tonyhansen> derek atkins: security of both can be solved by adjusting our picture
[19:16:28] <randy_g> Derek: security issues with either push or pull can be solved
[19:16:57] <tonyhansen> derek: if imap server is tied to mta, then can be considered together
[19:17:03] <randy_g> Derek: e.g., with push you can tie IMAP and submit servers together and they trust each other
[19:17:23] <tonyhansen> derek: can use a single use url
[19:17:28] <randy_g> Derek: with pull, a single use URL is an approach that works and makes things easy for the client
[19:17:41] <randy_g> Derek: so security issues can be solved either way
[19:17:49] <tonyhansen> derek: single use url comes ffom imap server
[19:17:53] <randy_g> Derek: so push vs pull is an architecture, not security issue
[19:18:14] <randy_g> Greg: has another concern with pull
[19:18:23] <tonyhansen> greg: pete didn't do advocacy -- still hasa concern of pull -- race condition
[19:18:26] <randy_g> Greg: concerned about race conditions with three servers execuritng a pull
[19:18:42] <randy_g> Greg: e.g., references to objects that have been deleted
[19:18:56] <randy_g> Greg: or references to object that should be deleted but can't be because therte
[19:19:00] <randy_g> s a pending pull
[19:19:17] --- rjs3 has left
[19:19:26] <NFreed> If this race condition is a real concern (I don't think it is) you could have a
[19:19:27] <tonyhansen> randy: thinks there will be race conditions with both
[19:19:32] --- rjs3 has joined
[19:19:36] --- warlord has left: Lost connection
[19:19:40] <NFreed> flag on the server that says "delete after pull". But I think this causes more
[19:19:43] <NFreed> problems than it solves.
[19:20:10] <MRCrispin> if you want to delete that powerpoint presentation after sending, then you have an FCC problem with push since the FCC will include the powerpoint.
[19:20:19] <tonyhansen> randy: overriding choices are between do we want to add message extration to submit, or submission aspects to imap
[19:20:36] <rjs3> (delayed) it seems poor to force the MTA and the IMAP server to be combined
[19:21:06] <tonyhansen> ted: race conditions in push are more manageable
[19:21:45] <tonyhansen> ted: pull race conditions are worse (can't get to mta? what do I keep around in my queue? the tokens?)
[19:22:00] <NFreed> sure, you couldn't set the flag in such cases. Regardless, I think this is being
[19:22:04] <NFreed> blown out of proportion.
[19:22:15] --- BP has left
[19:23:28] <tonyhansen> ted: case: local smtp servers won't be able to access his imap server
[19:24:01] <tonyhansen> glenn: in his mind, a convergence is happening here
[19:24:30] <tonyhansen> glenn: there is only a conclusion if there IS a tight coupling between imap and submit servers
[19:24:35] --- Hippasus has left: Disconnected
[19:25:19] --- nsb has left: Disconnected.
[19:25:37] <tonyhansen> glenn as chair: when going over pull, imap server can put thing together or should it be client submitting the whole thing?
[19:25:50] <tonyhansen> pete: gave ned's comment about race condition
[19:26:56] <tonyhansen> randy: it's a wash if having an local smtp and unreachable imap because can't send maile ither way
[19:27:14] <cnewman> If there is a tight coupling between IMAP and SMTP submit, then should there also be a tight coupling between IMAP and XMPP? How about SIMPLE? Why should the storage be coupled to the transport?
[19:27:31] <tonyhansen> ted: makes a diff because who keeps knowledge of who is responsible for delivering the msg
[19:27:46] <tonyhansen> ted: error conditions will be different
[19:28:45] <tonyhansen> ted: it becomes difficult when there is an expanded concept of where the messages are to be assembled vs. tightly coupled
[19:29:00] <randy_g> Chair: our charter is wireless handsets
[19:29:04] <tonyhansen> glenn: with wireless, you're going to lose connection a lot and phones are stolen
[19:29:57] <tonyhansen> tony: read chris's notes about coupling
[19:30:12] <randy_g> Greg: the way pull needs to work is that the server can't give 200 OK until final assembly has been done
[19:30:26] <tonyhansen> greg: submit's 200 okay can't be given until full msg has been combined together
[19:30:27] <alexeymelnikov> The client can delete pieces after submission when it connects to IMAP. Most client already set flags on an IMAP message (e.g. $Forwarded) after a message is sent.
[19:30:29] <randy_g> Greg: because that way the deletions can be done, the URLs canbe resolved, etc/
[19:31:10] <tonyhansen> someone: operators must take responsibility over data they're putting out on the internet, so must be able to tell client that we can't accept certain content
[19:31:29] <tonyhansen> greg: must expand error codes: quarantined content, existent client
[19:31:37] <randy_g> Greg: so we'd need a richer set of error codes in Submit if we did pull
[19:31:38] <hardie> Chris: can you recast that in a "if you are going to support forward without download, do you need to have a tight coupling between storage and transport"?
[19:31:44] <cnewman> Putting on my server vendor hat: we're very resource constrained in today's economy and do not have the resources to implement push on the server side -- it's just too complex. However, we do have the resources to implement pull. It seems the client vendors who need this will implement whatever they need, regardless of push vs. pull, but if the server vendors don't implement push until they're paid lots of money, it won't deploy. I suggest a poll of server vendors on this topic.
[19:32:04] --- warlord has joined
[19:32:13] <MRCrispin> I second the call for a poll of server vendors
[19:32:33] <rjs3> I agree with chris and mark
[19:32:36] <hardie> I think a poll of implementors of all of the pieces would be more appropriate (speaking personally, natch)
[19:32:45] <alexeymelnikov> +1 for pull
[19:32:54] <MRCrispin> +2 for pull
[19:33:05] <tonyhansen> randy: reading chris' and mark's remarks
[19:33:07] <rjs3> I'm in the same situation as Chris
[19:33:49] <alexeymelnikov> (I am a server implementor, both for SMTP and IMAP)
[19:34:46] <randy_g> (Ted reads his Jabber reply to Chris)
[19:34:46] <tonyhansen> randy: who here are server implementors?
[19:34:53] <tonyhansen> 3 raised their hands
[19:34:59] <rjs3> <raises hand>
[19:35:10] <tonyhansen> ted: asks about client implementors?
[19:35:25] <smaes> <raises hand as server implementor>
[19:35:41] <MRCrispin> <raises hand as server and client implementor>
[19:36:06] --- memo56 has joined
[19:36:10] <tonyhansen> alexey: are you concerned about client needs power?
[19:36:16] <randy_g> Ted: doesn't think client work is the same for pull vs push
[19:36:37] --- memo56 has left
[19:36:43] <randy_g> Alexey: Cyrus, as client vendor, says can do either push or pull
[19:36:57] <randy_g> Ted: asks that Cyrus post this to the list
[19:37:11] <randy_g> Ted: please read security review posted to list, it is different from what Derek said
[19:37:27] <randy_g> Ted: if go with URLAUTH we'd need SHA1 not HMAC
[19:37:32] <alexeymelnikov> Actually I said that Cyrus is in favour of pull
[19:37:50] <tonyhansen> ted: to summarize security review: recommendation on urlauth, then look at sha1 not hmac, timeliness with urls is an issue
[19:37:57] <tonyhansen> ted: need operational experience
[19:38:00] <randy_g> Ted; we'd need to split the tokens
[19:38:18] <MRCrispin> agreed on SHA1...HMAC was a placeholder. would like suggestions for better choice than 128 bits
[19:38:20] <tonyhansen> ted: please everyone, read the security review
[19:38:47] <tonyhansen> alexey: latest version of urlauth allows tokens to be generated either way
[19:38:53] <tonyhansen> (on server or client)
[19:39:09] <MRCrispin> question: should HMAC be deleted entirely in favor of SHA1?
[19:39:20] <tonyhansen> ted: read the security review
[19:39:35] <randy_g> Greg: does both client and server
[19:39:36] <tonyhansen> (that was to everyone, not just Mark :-) )
[19:39:41] <NFreed> what security review is this?
[19:39:51] <randy_g> Greg: PC based clients have enough to do either push or pull, and may prefer pull
[19:39:56] <tonyhansen> greg: as an implementor, would probably prefer pull,
[19:39:56] <eburger> Check the list. send out at beginning of session (to Ned)
[19:40:10] <randy_g> Greg: but mobile device clients are more limited, don't want to open extra TCP connection
[19:40:24] <tonyhansen> greg: for wireless, push will be easier
[19:40:35] <randy_g> Greg: for evidence, see that both M-IMAP and WAP MM1 use single TCP connection and do everything on one server
[19:40:35] <tonyhansen> greg: but more important to pick one, any one
[19:40:48] --- BP has joined
[19:40:50] <tonyhansen> nathaniel borenstein @mike
[19:41:03] <rjs3> ...but mobile clients will need to open the TCP connection anyway when they're not forwarding a message -- we're only solving forward-without-download here
[19:41:17] <randy_g> Comment that community is discussing major changes to SMTP, so push model isolates this
[19:41:24] <eburger> Poll for last comments...
[19:41:26] <tonyhansen> just when we're talking about changing smtp in large ways, we're talking about tying smtp and imap together?
[19:41:38] <randy_g> Comment: as a mobile carrier, we like a single TCP conenction; second TCP connection is too expensive
[19:42:04] <eburger> [Nathaniel was saying that Push would insulate clients from SMTP changes]
[19:42:28] <tonyhansen> someone: need to make guarantees about objects not goigng away until needed
[19:42:54] <MRCrispin> that point can go both ways though, since current Push SUBMIT command passes through SMTP responses
[19:43:01] <tonyhansen> pete: how about that poll? the poll is a bad idea
[19:43:16] <tonyhansen> pete: we need more analysis, but it's not being done
[19:43:23] <randy_g> Pete: let's not do a poll; we need more analysis, not just opinions from people who think the answer is obvious
[19:43:29] <rjs3> I agree. tying SMTP and IMAP with push when SMTP is about to undergo a lot of change is poor
[19:44:51] <randy_g> Ted: a fundamental question is: where should assembly occur?
[19:44:56] <rjs3> (put another way, defining SMTP extensions, then redefining them in IMAP seems poor)
[19:45:12] <tonyhansen> (comment was from sam suberman (sp?))
[19:45:19] <randy_g> Ted: some people say assemply on IMAP server is always best, but someone is commenting that as an implementor it is better to assemble on submit server
[19:45:39] <NFreed> it can be done in a way that requires only minimal config changes on the IMAP
[19:46:00] <NFreed> server to add support for additional extensions. However, it is VERY dangerous,
[19:46:16] <NFreed> in that the necessary security considerations aren't likely to be fully thought out.
[19:46:18] <tonyhansen> (suberman -> silberman)
[19:46:28] <NFreed> And the only way you solve this problem is by placing an additional requirement on
[19:46:36] <randy_g> My SUBMIT draft uses ANNOTATE to avoid IMAP server needing to know about submit extensions
[19:46:42] <NFreed> SMTP submit extensions to document their impact and how to handle them in
[19:46:48] <NFreed> IMAP PUSH. This sucks.
[19:47:03] <randy_g> Chair: first question is: where is best place to do assembly
[19:47:27] <tonyhansen> glenn: where is best place to do assembly 1) in client 2) imap 3) submit 4) option to do both imap and submit
[19:47:34] <NFreed> Randy, unfortunately this doesn't work out well. Clients need a way to
[19:47:51] <NFreed> discover the extensions that are available. This can be fixed, but then you
[19:48:02] <NFreed> have the problem that you cannot just blindly pass parameters through.
[19:48:09] <NFreed> Small example: SASL AUTH=.
[19:48:12] <randy_g> Ned, I agree, push makes it ugly
[19:48:15] <tonyhansen> chair: hum for room: in imap server?
[19:48:24] <cnewman> Probably best to do assembly on IMAP if all pieces come from IMAP (CATENATE). Best to do assembly on Submit server if pieces come from multiple locations.
[19:48:33] <tonyhansen> lisa d: why do we need to decide that?
[19:48:47] <MRCrispin> I agree with Chris
[19:48:52] <rjs3> I also agree with chris
[19:49:08] <tonyhansen> ted: we need to know where assembly is occurring so we know when it's been complete
[19:49:21] --- claudioallocchio has joined
[19:50:00] <tonyhansen> randy read chris' comment
[19:50:07] <tonyhansen> pete: agrees
[19:50:39] <tonyhansen> pete: if imap is doing it, then this changes dynamic for the future
[19:50:49] <tonyhansen> pete: where are we going?
[19:51:10] <tonyhansen> randy: reiterates architectural questions -- need to keep an eye on the future
[19:51:17] <tonyhansen> ted: disagrees
[19:51:50] <tonyhansen> ted: we do not want to expand this to composition protocol -- we have a task -- and the schedule is slipping
[19:52:13] <randy_g> I agreed that we needed to focus on the task at hand and not take on extra work, but we should consider the arch. ramifications of either choice
[19:52:15] <tonyhansen> ted: the charter says we're talking about imap content being forwarded
[19:52:19] --- claudioallocchio has left: Disconnected
[19:53:02] <randy_g> Chair: the horror of the future is adding every transport to IMAP, or adding multiple URL schemes to submit
[19:53:04] <tonyhansen> glenn: the horror of the future is we'd need to teach imap to know about submission servers for smtp, nntp, etc. vs. teaching submit to do imap, http, etc.
[19:53:31] <tonyhansen> pete: one danger of ted's line is we don't want to think in terms of what's the fastest thing to do
[19:53:48] <randy_g> Pete: disagrees with Ted: we don't want to just consider fastest solution; fastest solution is to bold sendmail to imap and that Would Be Bad
[19:53:55] <tonyhansen> pete: the fastest is to do push (bolt smtp to imap)
[19:53:57] <rjs3> Its not entirely clear to me what the fastest thing to do is
[19:54:05] --- claudioallocchio has joined
[19:54:20] <NFreed> I agree; people are _seriously_ underestimating the complexity of push.
[19:54:34] <randy_g> Lisa: even if the goal is just forwar w/o download, not composition, and just easily extensible, then [[ missed ]]
[19:54:34] <tonyhansen> ted: luckily mm1 is already standardized (haha)
[19:54:41] <NFreed> Heck, as presently speced it requires implementation of ANNOTATE.
[19:55:06] <resnick> Even I think that's a bad thing.
[19:55:06] <randy_g> Ted: we need to build protocols that will be deployed. Leaving options makes for more complexity and no deployment
[19:55:09] <NFreed> How many implementations of ANNOTATE are there?
[19:55:13] <tonyhansen> ted: if we don't do anything, we really will wind up with mm1
[19:55:24] <rjs3> none
[19:55:26] <MRCrispin> I don't know of any
[19:55:29] <resnick> I think we need to spec out wihtout ANNOTATE
[19:56:10] <randy_g> I'm really concerned with adding submission to IMAP as a separate, paralell mechanism
[19:56:11] <tonyhansen> how many implementations of annotate will there be?
[19:56:19] <alexeymelnikov> I still assembly in IMAP/vs in SMTP/vs both is still orthogonal to PUSH vs PULL (except that PUSH can only do IMAP assembly)
[19:56:19] <cnewman> One of the stronger arguments against push is that it is deceptively simple. If doing push as a proxy, you have to parse and filter _every_ SMTP extension. Just think about the ramifications of an IMAP client sending a fraudulent AUTH= parameter.
[19:56:28] <randy_g> We'd need to add extensions to both, and we'd create two submission systems: one for IMAP clients, one for others
[19:56:32] <tonyhansen> chair: wants to take temperature of the room
[19:56:35] <kmurchison> Cyrus IMAP has no plans to implement it
[19:56:42] <tonyhansen> chair: where is best place to do assembly?
[19:56:48] <MRCrispin> UW imap has no plans to implement ANNOTATE
[19:56:56] <randy_g> Chair: calls for sense of room as to where is best place to do assembly: IMAP server, submit server, or both
[19:56:57] <MRCrispin> assembly should be in both
[19:57:04] <tonyhansen> hums went to imap server
[19:57:06] <rjs3> both, see chris's comment above
[19:57:17] <randy_g> I think the hums were pretty equal
[19:57:38] <resnick> clearly needs to be discussed on the list
[19:57:54] <tonyhansen> chair: of course, it will be taken to the list
[19:58:12] <NFreed> very true; this has been a good, technical discussion.
[19:58:28] <randy_g> Chair: security analyis in two weeks
[19:58:43] <randy_g> Chair: wants two more documents, very partisan, as to why push and why pull are better
[19:58:48] <NFreed> It is a tough choice precisely because there are advantages and disadvantages to both.
[19:58:56] <randy_g> Chair: then we can have an interim and make a choice
[19:58:56] <tonyhansen> chair: 2 weeks to get final "why X is great" to the list
[19:59:26] <tonyhansen> chair: need to review security docs
[19:59:26] <NFreed> I'd also like to see the various proposals updated. Various suggestions have
[19:59:32] <NFreed> been made to simplify both of them.
[19:59:39] <randy_g> Ned, I agree, there are compelling reasons both for and against both, but I consider the future risks to be worse with push than with pull
[19:59:59] <tonyhansen> chair: need to see comments from various types of implementors as well
[20:00:00] <eburger> Calling for a "Push is Great" document editor, and a "Pull is Great" document editor. Any takers from the Radio Audience
[20:00:08] <NFreed> Randy, I personally agree with you. My point is that it isn't a clear-cut choice.
[20:00:18] <NFreed> And the IETF has enough trouble with those, let alone with this sort of thing.
[20:01:01] <randy_g> Chair asks who is going to Voice on the Net in Santa Clara March 21-28
[20:01:02] <NFreed> Chris and I really need to work on the sec cons doc; no bandwidth for the partisan docs.
[20:01:44] <eburger> March 28 - April 1, but it doesn't sound like people are going
[20:01:45] <tonyhansen> greg wants to see pull narrowed down to one option
[20:01:46] <randy_g> Greg wants to see pull document narrowed down to one option
[20:02:09] <tonyhansen> ted: need 30 days to schedule interim meeting
[20:02:48] <randy_g> Ted: we hash the issue out on the list and then use interim to produce document we are willing to last call
[20:02:54] --- claudioallocchio has left: Disconnected
[20:02:54] <rjs3> Is there an opinion as to which option? (I think 1+2 myself, but...)
[20:03:07] <randy_g> Ted: we need to have the decision made before the interim
[20:03:21] <randy_g> I'd also go with 1+2
[20:03:24] <tonyhansen> ted: will commit to joining in on interim conference call, no matter the proposal
[20:04:15] <alexeymelnikov> I probably prefer PULL option 2
[20:04:21] <tonyhansen> chair: wondering if we can get away with just having "why X is great" or do we need newer fleshed out proposals?
[20:04:29] <cnewman> If I had to settle on one push model, I'd settle on CATENATE+single-BURL. It does FCC in the simplist way and is easier to understand.
[20:04:33] <tonyhansen> pete: he would do better with fleshed out proposals
[20:04:50] <cnewman> sorry, I meant "settle on one pull model"
[20:04:55] <tonyhansen> greg: agrees
[20:05:04] <NFreed> i don't have a problem with partisan docs espousing particular solutions, but
[20:05:07] <NFreed> updated proposals are a must.
[20:05:07] <tonyhansen> chair: agrees
[20:05:11] <randy_g> Chris's suggestion also is easy to expand to BDAT/BURL in the future
[20:05:21] <MRCrispin> CATENATE + single-BURL is definitely the simplest pull model. Embedded URI can be done in the future
[20:05:49] <NFreed> Yep, and that's what we need the PULL spec to say now IMO.
[20:05:53] <randy_g> Chair: let's get updated documents, then identify client and server vendors, talk to them off line, and get them to speak up
[20:05:53] <tonyhansen> chair: so we need to have updated tech docs, and solicit opinions from vendors (a job from the chairs)
[20:06:07] <randy_g> Chair: we've seen cases where vendors haven't spoken up unless directly asked
[20:06:33] <tonyhansen> greg: are people hardening their views rather than keeping their minds open to be swayed one or another?
[20:07:32] <tonyhansen> randy: he's seen some evidence of people becoming rigid, but there are also people who have changed their opinions
[20:07:43] --- Lisa D has joined
[20:07:57] <tonyhansen> randy: people are more willing to say "both are possible, but we just need to handle the issues"
[20:08:35] <tonyhansen> randy: do we have enough people present (in room and in jabber) to really make a decision?
[20:09:05] <tonyhansen> ted: the security reviewer was sam hartman
[20:09:10] <MRCrispin> is this the security reviewer of URLAUTH?
[20:09:13] <randy_g> Ted: security review is Sam Hartman, so feel free to talk to him personally
[20:09:13] <tonyhansen> yes
[20:09:43] <randy_g> Chair: we're going to get updated security considertions from Chris and Ned
[20:09:49] <tonyhansen> chair: we'll be getting security considers from ned + chris; mark will update pull draft
[20:09:59] <randy_g> Chair: Mark is going to update Pull draft
[20:10:08] <tonyhansen> chair: pete + randy will update push
[20:10:22] <randy_g> Pete wants me to not use ANNOTATE
[20:10:24] <tonyhansen> pete: can push be done without annotate? would like to see that
[20:10:28] <cnewman> Pete is right.
[20:10:37] <NFreed> yep. The added complexity of annotate is considerable.
[20:10:41] <tonyhansen> pete: is "any mailbox" a bad thing
[20:10:59] <randy_g> But then how do we avoid creating a parallel submission mechanisn and also avoid makinh the IMAP server know all about submit extensions
[20:10:59] <tonyhansen> chair: can this be done in two weeks?
[20:11:00] <MRCrispin> i'm unclear what is to be done in pull draft
[20:11:10] <MRCrispin> URLAUTH draft needs to address the security considerations.
[20:11:16] <resnick> Fleshing out the mechanisms.
[20:11:52] <cnewman> For pull, we need to respond to the security review from Sam.
[20:11:52] <tonyhansen> randy: asking mark's question, then saw pete's comment
[20:12:02] <tonyhansen> greg: need to pay attention to race conditions
[20:12:09] <tonyhansen> chair: next item
[20:12:14] <resnick> Some analysis of race conditions also mentioned.
[20:12:15] <tonyhansen> chair: imap4 profile
[20:12:22] <tonyhansen> chair: for lemonade
[20:12:58] <tonyhansen> chair: looking for editor,but not until after current work is further along
[20:13:14] <tonyhansen> chair: on to "p-imap" by stephane maes
[20:13:42] <tonyhansen> slides at http://flyingfox.snowshore.com/i-d/lemonade/slides59/PIMAP-Draft_Overview_IETF59.ppt
[20:14:07] --- ludomp has left
[20:15:38] --- galvinjamesm has left
[20:16:29] <tonyhansen> clients can set notification mode (in-band/out-band) & device address; set view and notification filters; send out messages; exchange compression capabilities
[20:20:07] <randy_g> Focus is on user experience, not protocol choice (push vs pull) Security, bandwidth usage, notifications are crucial Adds XSETPIMAPPREF/XGETPIMAPPREF Adds XDELIVER for message submission groups commands Runs over HTTPS and over TCP. Can run over other bindings possible Multiple notification mechanisms: WAP PUSH, in band HTTPS binding uses keep-alives for long-lived HTTP session
[20:20:39] <resnick> time check?
[20:22:37] <NFreed> yes, and isn''t a lot of this out of scope?
[20:22:46] <randy_g> Speaker: wants WG to consider P-IMAP as an approach
[20:23:15] <randy_g> (an approach to the IMAP profile issue)
[20:23:35] <tonyhansen> greg: this looks familiar
[20:23:46] <randy_g> Greg: it looks very offensive from a protocol point of view, but looks very similar to what we've done as well
[20:23:52] <tonyhansen> greg: hasthis been implemented?
[20:24:01] <tonyhansen> stephane: yes
[20:24:08] <randy_g> Oracle has implemented this with some GSM carriers
[20:24:22] <tonyhansen> greg: sees this as prototype of lemonade charter
[20:24:45] <randy_g> Greg: this raises the issue of push, which is not now in the charter. Do we want to take it on?
[20:25:34] <tonyhansen> greg: push for notification
[20:25:36] <randy_g> My comment about implemention with GSM carriers was an attempt to capture what the speaker said, it is not a statement from me
[20:25:53] <tonyhansen> pete: we have server to server notifications
[20:26:03] <tonyhansen> greg: this is different -- server to client notifications
[20:26:24] <randy_g> Chasir: Take to list; could fit as first draft of IMAP profile that we had asked for an editor, but want to take this to list
[20:26:38] <randy_g> Stephane volunteers to be editor if this will be a first draft
[20:26:41] <tonyhansen> chair: use this as a first draft of profile document? (stephane volunteers) take this discussion to the list
[20:26:59] <tonyhansen> chair: recap of wg deliverables
[20:27:03] --- Lisa D has left: Disconnected
[20:27:04] <resnick> I wouldn't be in favor of that, personally
[20:27:28] <resnick> (Using that as a profile)
[20:27:38] <tonyhansen> chair: milestones shifted
[20:27:49] <rjs3> me either
[20:28:47] <tonyhansen> greg: the milestones are agressive -- change submit imap/submit extensions to jul 04
[20:29:03] <tonyhansen> greg: channel to sep04
[20:29:21] <tonyhansen> adjourning
[20:29:23] --- hardie has left
[20:29:34] <randy_g> Chair will post to list on interim (conference call or face to face)
[20:29:38] --- jean has left
[20:29:47] --- tonyhansen has left
[20:29:49] --- smaes has left
[20:29:56] --- mwener has left
[20:30:10] --- warlord has left
[20:30:15] --- rjs3 has left
[20:30:21] --- alexeymelnikov has left
[20:30:34] --- kmurchison has left
[20:31:16] --- Glenn Parsons has left: Disconnected
[20:31:43] --- cnewman has left
[20:32:07] --- resnick has left
[20:32:25] --- eburger has left
[20:32:26] --- MRCrispin has left
[20:33:53] --- kdz has left: Disconnected
[20:34:04] --- NFreed has left: Disconnected
[20:35:23] --- rlbob has left
[20:35:58] --- BP has left
[21:06:30] --- randy_g has left: Disconnected
[21:34:32] --- kdz has joined
[21:41:42] --- kdz has left