[11:49:34] --- ohm has joined
[12:20:00] --- ohm has left
[12:23:04] --- LOGGING STARTED
[12:34:37] --- LOGGING STARTED
[12:35:57] --- LOGGING STARTED
[12:37:09] --- ohm has joined
[12:39:41] --- Hollenbeck has joined
[12:42:51] --- resnick has joined
[12:43:23] --- ohm has left: Replaced by new connection
[12:43:24] --- ohm has joined
[12:44:04] --- leg has joined
[12:46:49] --- leg has left: Logged out
[12:47:56] --- leg has joined
[12:51:45] --- amelnikov has joined
[12:51:46] --- robsiemb has joined
[12:53:20] --- dbrashear has joined
[12:55:39] --- shmaes has joined
[12:57:49] * robsiemb has set the topic to: lemonade working group - welcome
[12:57:49] --- randy has joined
[12:58:07] * randy has set the topic to: lemonade working group
[12:58:08] * resnick and leg will be scribing
[12:58:15] <resnick> Agenda
[12:58:17] <resnick> today:
[12:58:19] --- pguenther has joined
[12:58:22] <resnick> status review:
[12:58:30] --- corby has joined
[12:58:33] --- hildjj has joined
[12:58:33] --- shmaes has left: Replaced by new connection
[12:58:34] --- shmaes has joined
[12:58:42] <resnick> - goals, s2s notification, mms future delivery, pull trio
[12:58:47] <resnick> profile
[12:58:55] <resnick> security discussion
[12:59:05] <resnick> media conversion
[12:59:12] <resnick> deployment challenges
[12:59:29] <resnick> status
[12:59:43] <resnick> WGLC status, that is
[12:59:51] <resnick> Goals is in the rfc-editor queue
[13:00:12] <resnick> s2s - informational, needs chair write-up
[13:00:13] <resnick> mms mapping - same
[13:00:27] <resnick> future delivery - nits review needed
[13:00:54] <resnick> burl - same
[13:01:13] <resnick> urlauth - need new draft
[13:01:35] --- shmaes has left: Replaced by new connection
[13:01:37] --- shmaes has joined
[13:02:33] <leg> -05 is ready to go but resnick wants to discuss a couple of technical issues
[13:02:47] <leg> resnick is now speaking about ...
[13:03:14] <leg> url interpretation: basic concern is "what is the base url for relatively interpretation? does it change in selected state as opposed to authenticated state?"
[13:03:54] --- shmaes has left: Replaced by new connection
[13:03:55] --- shmaes has joined
[13:04:43] <leg> "if you're going to use an absolute url we have an issue of a server needing to know it's own domain name and do you always want to include the username"
[13:05:02] <leg> an absolute url without a user seems to indicate an anonymous user.
[13:05:27] <leg> issue 1: base for relative urls
[13:05:48] --- lisa has joined
[13:05:57] <leg> philip gunther: favor of changing base url in selected state
[13:06:15] --- tonyhansen has joined
[13:06:23] <leg> chris newman: the complexity is how to deal with ".." in a relative url?
[13:06:40] <leg> philip and chris are now going to mud wrestle to determine this.
[13:07:09] <amelnikov> BTW, there are few issues with ABNF in the IMAP URL RFC, I've sent a message to Chris, but he did not respond
[13:07:15] <leg> ".." moves in URI space but not mailbox space. imap urls aren't really hierachical.
[13:07:17] <lisa> Alexey, you listening?
[13:07:22] <lisa> (pete asked :)
[13:07:42] <amelnikov> I am not listening to audio yet
[13:07:51] <lisa> ahh
[13:08:08] --- cnewman has joined
[13:08:12] <leg> seems to be consensus for selected state changing base URL for relative urls.
[13:08:26] <randy> specifically, to "this mailbox"
[13:08:36] <amelnikov> I prefer to not switch the base in different states
[13:08:40] <leg> issue 2: absolute URLs. are they allowed? is the client required to use relative URLs where possible?
[13:08:45] <cnewman> I responded to your first message about IMAP URLs, but haven't gotten to your second message yet...
[13:09:13] <leg> alexey, what's your reason for not changing base URL? i will pass it on.
[13:09:25] <amelnikov> Chris: I don't think we can publish CATENATE before you answer my second question. Otherwise all examples might be wrong
[13:10:10] <amelnikov> Larry: simplicity on the client side, IMHO. Even though Pete's example about selected state seems reasonable.
[13:10:55] <leg> they are now talking about getting at other user's mailboxes via URLs and whether this requires absolute URLs. i'm getting confused.
[13:11:25] --- cyrus_daboo1 has joined
[13:11:37] --- shmaes has left: Replaced by new connection
[13:11:38] --- shmaes has joined
[13:11:54] <leg> on some servesr, you can use relative URLs to get at other user's mailboxes. so that doesn't mean that absolute URLs are required.
[13:12:32] <leg> general agreement that we should force clients to use relative URLs and have a different extension for absolute URLs.
[13:12:38] <leg> klensin causes feedback.
[13:13:14] <leg> klensin believes that disallowing absolute URLs is weird.
[13:13:27] <amelnikov> Why have URLs at all if we can only use relative?
[13:13:52] <amelnikov> I agree with John. There is no technical reason. We just have to describe this properly
[13:14:39] <randy> how does the client know the syntax or proper name to refer to another user's mailbox? It knows it because it is identical to what is issues in SELECT?
[13:14:41] <leg> cnewman: believes we should require relative URLs but need to make clear that "/random/mailbox" refers to "random/mailbox"
[13:14:53] <leg> randy: yes.
[13:15:10] <leg> resnick: allow URLs for further extensibility.
[13:15:27] <leg> eventually allow other servers or http:// or whatever.
[13:16:03] <leg> consensus that absolute URLs are out for this extension.
[13:16:03] --- klensin-ietf has joined
[13:16:28] <leg> ;AUTH= is also not allowed.
[13:16:38] <amelnikov> Does this mean that absolute URLs are syntactically allowed, but not supported by the CATENATE extension?
[13:16:48] <leg> correct
[13:17:27] <amelnikov> Ok, than I need to update examples once again ;-)
[13:17:30] <leg> absolute URLs -> get a NO back from the server.
[13:17:43] <robsiemb> same with AUTH
[13:17:49] --- cyrus_daboo has joined
[13:18:06] --- cyrus_daboo1 has left
[13:18:19] <leg> pete is wrapping up presentation. any last complaints?
[13:19:19] <resnick> Profile:
[13:19:33] <cyrus_daboo> alexey - are you getting any audio?
[13:19:40] <resnick> Stephane describes the new content.
[13:19:41] <amelnikov> Cyrus: no
[13:19:51] <cyrus_daboo> OK, same here :(
[13:20:07] <amelnikov> I guess we are spoiled with audio now :-)
[13:20:30] <resnick> Does anybody want me to hook up iChat?
[13:20:47] <dbrashear> i can do the same if needed (does ichat allow multiple listeners?)
[13:20:59] <amelnikov> Pete: would there be another WGLC for CATENATE?
[13:21:02] <resnick> (It only allows one at a time.)
[13:21:09] <resnick> Alexey: Yes.
[13:21:20] <resnick> WGLC after -05 is out.
[13:21:35] <amelnikov> Pete: I need to talk to you about CATENATE, after the meeting
[13:21:37] <resnick> Greg commenting on profile. Not sure if media conversion is required.
[13:21:42] <cyrus_daboo> Have we decided whether to split out APPEND extension syntax into another doc to help both CATENATE and ANNOTATE? Is that an IMAPext issue?
[13:22:22] <amelnikov> Cyrus: I have a document published. Updating references should be easy, IMHO
[13:22:36] <resnick> Greg thinks media coversion should be required.
[13:22:55] <resnick> Not necessarily the streaming stuff.
[13:24:00] --- randy g has joined
[13:24:19] <cyrus_daboo> Alexey: OK I see that - looks OK. Will discuss more tomorrow in imapext...
[13:25:04] --- shmaes has left: Replaced by new connection
[13:25:05] --- shmaes has joined
[13:25:47] --- randy has left: Replaced by new connection.
[13:25:58] <amelnikov> Cyrus: I am willing to take SEARCH extensions out, if this is going to speed up the document. I think one more revision is needed and it can be last called
[13:26:37] <cyrus_daboo> Pete: I can live without audio today, but if the same problem occurs tomorrow for IMAPext (which is in the same romm I think), then I would like to use iChat. Perhaps someone can ask the UOregon folks about fixing audio in that room in the meantime...
[13:31:04] --- randy g has left
[13:31:16] --- randy g has joined
[13:31:25] --- resnick has left: Replaced by new connection
[13:31:26] --- resnick has joined
[13:31:28] <amelnikov> (test, please ignore)
[13:31:41] --- shmaes has left: Replaced by new connection
[13:31:42] --- shmaes has joined
[13:32:06] <resnick> Sorry, I was gone for a while
[13:32:11] <resnick> (Net issues)
[13:33:10] <robsiemb> discussion has been going on about what specifically is in profile 1, and if media conversion (or how much) should be a part of it
[13:33:57] --- corby has left
[13:35:27] <robsiemb> question (greg?): are the requirements solely on the server or are they on the client as well?
[13:35:47] <robsiemb> chairs: its both
[13:36:17] <robsiemb> phillip: Its more of a MUST on the server and a SHOULD on the client
[13:37:22] <robsiemb> stephane: I think we need to add a normative section for the server extension requirements.
[13:38:08] <resnick> Alexey, any comments on profile stuff?
[13:38:19] <robsiemb> seems to be agreement that one document would have both strict server requrements and a tutorial/descriptive/example section for the use cases.
[13:39:44] <amelnikov> Yes, I think the document should be more explicit what is required from the server
[13:40:34] --- corby has joined
[13:40:38] <robsiemb> further discussion about should we make clients a MUST support or not.
[13:40:39] <resnick> Yes, that's the plan alexey.
[13:40:46] <resnick> The issue is the client.
[13:40:49] <pguenther> should there be any normative requirements on clients?
[13:40:51] <randy g> Alexey -- do you think it should impose restrictions on the client?
[13:41:16] <robsiemb> chairs: feeling of the room appears to be that they shouldn't have to be requirements about it.
[13:41:31] <robsiemb> barry: if we don't put in requirements on the client, they can claim "lemonade compliance" freely.
[13:41:32] <resnick> The sense of the room is that clients SHOULD do stuff, but the servers MUST.
[13:41:39] <amelnikov> I don't think how we can reasonably reqiure anything from clients
[13:42:53] <randy g> Pete: clients "SHOULD" or "Normally, clients do ..."
[13:42:55] <randy g> ?
[13:43:09] <resnick> Klensin: Recommendations to clients are fine. Conformance statements will be followed by good clients (who would have done it anyway), but will be ignored by bad clients.
[13:43:32] <amelnikov> Exactly (agreeing with John)
[13:43:34] <resnick> Randy: Trying to capture the room at the moment.
[13:43:58] <resnick> I'm now not sure that they feel that is should be SHOULD.
[13:44:55] <cyrus_daboo> wow - audio has just started up
[13:45:08] <robsiemb> someone just came in ehre aned kicked it
[13:45:12] <resnick> The guy just came in the room to fix it.
[13:45:18] <cyrus_daboo> Great - thanks!
[13:45:40] <robsiemb> chairs: rough concensus on perscriptive for server and descriptive for client
[13:45:43] --- shmaes has left: Replaced by new connection
[13:45:43] --- shmaes has joined
[13:45:52] <resnick> Alexey, Cyrus: anything else for profile?
[13:45:59] <cyrus_daboo> nope
[13:46:54] <resnick> Going on to the security issues
[13:47:07] <resnick> Sam Hartman's issues:
[13:47:21] <resnick> 1. State recovery at apps layer:
[13:47:48] <resnick> Sam recommends doing a session layer instead and not do it in the apps layer.
[13:48:04] <resnick> 2. Security model:
[13:48:23] <resnick> How do you deal with encrypted messages?
[13:48:51] <resnick> I'll talk about that in a sec.
[13:49:07] <resnick> 3. Security credentials for streaming
[13:49:36] <resnick> Now specifics:
[13:49:42] <resnick> Reconnect:
[13:50:10] <resnick> principles: don't reduce IMAP security, don't break IMAP security model
[13:50:56] <resnick> Proxy server would solve the problem, passing a cookie to the client for reconnection later.
[13:52:06] <resnick> This may just collapse into what we were talking about anyway.
[13:52:54] --- randy g has left
[13:52:59] <resnick> Randy: Is this resync or reauthentication we're talking about?
[13:53:02] --- randy g has joined
[13:53:03] --- shmaes has left: Replaced by new connection
[13:53:05] --- shmaes has joined
[13:53:48] <resnick> ekr: If the bandwidth is the issue, then re-use the same authentication scheme.
[13:53:52] <amelnikov> RECONNECT doesn't change how LOGIN/AUTHENTICATE verify users
[13:54:01] <resnick> ekr: Using a cookie opens up a passive attack.
[13:54:06] <cyrus_daboo> Regular desktop clients doing explicit disconnect/connect do benefit from RECONNECT - so its not just the quick connection loss problem that is being solved here.
[13:54:23] <amelnikov> Checking SID validity is a second step, once authentication is successful
[13:54:33] <randy g> Cyrus: yes, indeed, thanks
[13:55:32] --- shmaes has left: Replaced by new connection
[13:55:33] --- shmaes has joined
[13:56:33] <resnick> Rob: If we need to speed up the authentication, we can come up with a new mechanism.
[13:56:49] <resnick> corby: Pretty much agreeing with everyone.
[13:56:53] <cyrus_daboo> I should also point out that Chris (or was it Mark?) has had some very strong words to say about IMAP proxies based on experience/problems with doing the same for SMTP.
[13:57:24] <robsiemb> I was going to mention that, but its not clear we're actually talking about using proxies here, it was just one previously proposed method
[13:57:34] <resnick> Edwin: What about single use schemes?
[13:57:46] <resnick> ekr: Yup, you're going to have to pull out the token again.
[13:57:57] --- corby has left: Disconnected
[13:58:47] --- corby has joined
[13:58:51] <cyrus_daboo> We are talking about something that is going to maintain state on behalf of the client (i.e. a full blown IMAP client), and then we have to invent new protocol elements to get that state from the intermediary once the client has got its connection back.
[13:59:06] <leg> pete is talking about transcoding
[14:00:54] <robsiemb> problem is encrypted messages, which make transcoding tough to do on the server
[14:01:41] <robsiemb> [we are on slide 14, but it happens to be wrong when it talks about public and private keys]
[14:02:53] --- cyrus_daboo has left
[14:04:16] <robsiemb> pete describes the method where you can use an encrypted session key (in the user's private key), and the client can hand the key back to the server. Except for some inconveinentness.
[14:04:59] --- dcrocker has joined
[14:07:32] --- randy g has left: Replaced by new connection.
[14:07:33] --- randy g has joined
[14:09:36] <robsiemb> discussion of history
[14:11:30] --- randy g has left: Replaced by new connection.
[14:11:31] --- randy g has joined
[14:14:57] <robsiemb> pete discusses what we do with the decoded attachment once we are able to decode it
[14:15:00] <randy g> (test)
[14:15:22] <amelnikov> Pete suggestes that we can CATENATE a decrypted part
[14:16:16] <randy g> Pete suggested we CATENATE an encrypted message into a decrypted one, I think
[14:16:38] <robsiemb> right, something like APPEND (from URL) (with KEY)
[14:16:47] <amelnikov> Randy: Yes, this is what I meant
[14:17:10] <amelnikov> No more audio
[14:17:40] --- shmaes has left: Disconnected
[14:17:44] <robsiemb> Scott suggests getting together a group of apps and security people to look at this
[14:17:56] <randy g> Scott suggests a design team with a security area advisor, notes that this is a general problem, not limited to lemonade, notes OPES has it as well
[14:19:06] <randy g> Ned notes that he added transcoding to pmdf circa 1985, mostly to convert WP formats (e.g., WordStar, WordPerfect)
[14:19:35] <randy g> Ned says they ran into the "3-body problem" -- the information loss is so high that you end up with unusuable garbage
[14:20:50] --- randy g has left: Replaced by new connection.
[14:20:51] --- randy g has joined
[14:21:18] <robsiemb> Ned wants to know that there are compelling use cases for transcoding that won't be obsoleted quickly because server implementations can't keep up
[14:26:52] --- randy g has left: Replaced by new connection.
[14:28:47] --- randy g has joined
[14:28:50] --- randy g has left: Disconnected.
[14:30:54] --- randy has joined
[14:36:17] --- randy has left: Disconnected.
[14:36:33] --- randy has joined
[14:37:15] --- lisa has left
[14:40:50] <randy> (test)
[14:40:50] --- randy has left
[14:41:02] --- randy has joined
[14:41:17] <randy> (test)
[14:43:17] <Hollenbeck> This tool can be helpful for nits review: http://ietf.levkowetz.com/tools/idnits/idnits.pyht
[14:44:20] --- Hollenbeck has left
[14:46:51] --- resnick has left: Disconnected
[14:46:52] --- robsiemb has left: Lost connection
[14:46:52] --- cnewman has left: Lost connection
[14:46:52] --- corby has left: Lost connection
[14:53:57] --- randy has left: Disconnected.
[14:54:17] --- tonyhansen has left
[14:54:28] --- dbrashear has left
[15:11:28] --- leg has left: Disconnected
[15:12:26] --- ohm has left: Disconnected
[15:13:51] --- ohm has joined
[15:13:59] --- randy has joined
[15:15:46] --- shmaes has joined
[15:16:19] --- shmaes has left: Disconnected
[15:17:11] --- ohm has left
[15:21:08] --- randy has left: Replaced by new connection.
[15:21:09] --- randy has joined
[15:32:59] --- DougRoyer has joined
[15:46:43] --- randy has left: Disconnected.
[15:47:51] --- resnick has joined
[15:55:46] --- resnick has left
[16:04:49] --- dcrocker has left: Replaced by new connection
[16:04:49] --- dcrocker has joined
[16:04:49] --- dcrocker has left
[16:18:58] --- DougRoyer has left
[17:22:59] --- GregWhite has joined
[17:26:45] --- GregWhite has left
[17:28:25] --- GregWhite has joined
[17:28:32] --- GregWhite has left
[17:37:48] --- lisa has joined
[17:43:05] --- ohm has joined
[17:43:19] --- ohm has left
[17:46:19] --- lisa has left
[19:14:26] --- lisa has joined
[19:21:56] --- lisa has left
[21:46:50] --- Glenn has joined
[22:18:47] --- Glenn has left: Disconnected