[12:59:07] --- tonyhansen has joined
[13:41:21] --- Glenn Parsons has joined
[14:04:44] --- resnick has joined
[14:07:18] <Glenn Parsons> We will start shortly after lunch -- perhaps 5-10 minutes
[14:26:00] --- randy has joined
[14:29:31] --- robsiemb has joined
[14:35:33] --- smaes has joined
[14:37:41] <robsiemb> agenda bashing
[14:43:32] <resnick> Noted Well.
[14:43:41] <resnick> Me jabbering.
[14:43:46] * resnick jabbers
[14:44:16] --- hardie has joined
[14:44:32] <resnick> Dinner arrangements being made.
[14:45:49] <resnick> Discussion about start time being 12 or 1 goes on long enough to make it moot.
[14:47:38] <resnick> Agenda
[14:47:56] <resnick> status review of s2s notify, mms, future delivery, goals
[14:48:01] <resnick> pull trio
[14:48:04] <resnick> quick reconnect
[14:48:08] <resnick> media conversion
[14:48:13] <resnick> channel
[14:48:18] <resnick> profile (phase 1)
[14:48:23] <resnick> goals (phase 2)
[14:48:32] <resnick> end of current agenda
[14:49:33] <resnick> (Talk about unchartered items at the end to see if we want to amend charter)
[14:49:55] <resnick> alexey: add disconnected mode?
[14:50:12] <resnick> inserted at end of status review
[14:50:19] <resnick> (after pull trio)
[14:53:07] <resnick> End this evening round about 6, start up tomorrow 9.
[14:54:14] <resnick> Charter review/deliverables (see website)
[14:55:05] --- pguenther has joined
[14:56:48] --- hardie has left
[14:57:02] --- hardie has joined
[14:58:02] <resnick> Going though stuff since last meeting.
[14:58:58] <resnick> pete: catenate is ready for last call
[14:59:19] <resnick> we will have a 2 week WG last call on catenate-03
[15:00:18] <resnick> (starting today)
[15:00:21] <resnick> BURL
[15:01:17] <resnick> Will WG last call BURL as well.
[15:01:48] <resnick> After WG last call completes, will send all 3 (URLAUTH, CATENATE, BURL) to IETF Last Call.
[15:03:29] <resnick> s2s notify and mms mapping will go immediately to IETF Last Call.
[15:04:57] <resnick> new draft needed for future delivery
[15:05:10] <resnick> goals document, in IESG review.
[15:08:01] <resnick> Sam Hartman has a DISCUSS on the document.
[15:08:31] <resnick> The discuss probably applies to our work, but probably not to this document.
[15:11:02] <resnick> Comments from IESG:
[15:11:36] <resnick> Security model/CONNEG/trust model is probably outside of the scope of the document.
[15:11:55] <resnick> Special mailbox issues could probably be wordsmithed.
[15:13:18] <resnick> State recovery (that it doesn't belong at the apps layer): Yes, it should be dealt with by TCP, but it doesn't.
[15:14:26] <resnick> But again, doesn't apply to this document. Should be the quick reconnect document, and we need to explain in that document what the issues are.
[15:16:05] <resnick> Security for streaming issue: Again, wrong document. Point him to CHANNEL (or wherever it ends up)
[15:16:42] <resnick> Security considerations section weak: Is stronger needed in the goals document?
[15:19:11] <resnick> Dave: Maybe it would be useful to pump up the security considerations section.
[15:19:25] <resnick> Rob: It doesn't say much now. Probably worth it.
[15:20:02] <resnick> Dave: Do we have a good trust model language to start to address this?
[15:23:21] <resnick> Dave: Generally, the comments amount to "there's high-level architectural concerns", and it's not clear where else these discussions should take place other than the goals document.
[15:23:54] <resnick> Glenn: Could it go in the profile document?
[15:27:05] <resnick> (More discussion about where it belongs)
[15:32:22] <resnick> Idea is to beef up security considerations with stuff from Sam's list, but then point Sam to other documents for specific comments.
[15:33:47] <robsiemb> To rephrase, I think the goals document's security considerations should talk about the issues (in general, and not just limited to sam's list necessaraly), but not attempt to solve them, indicating that the solutions will need to be found by the implementation.
[15:34:41] <resnick> Back to the trio:
[15:35:04] <resnick> WG last call on BURL and CATENATE going out.
[15:35:12] <resnick> Disconnected mode:
[15:36:02] <resnick> Alexey: Changes?
[15:36:13] <resnick> Ted: No. RFC Editor note added and approved.
[15:36:48] <resnick> Quick Reconnect:
[15:37:40] <resnick> Alexey: Open issue: Would server need to maintain some state?
[15:38:48] <resnick> Are we doing accidental disconnects or long term disconnects?
[15:39:10] <resnick> The latter would be easier to get by the transport area.
[15:40:08] <resnick> Eric: We should work on intentional application disconnect.
[15:40:35] <randy> Whatever we do that helps normal disconnect/reconnect also helps accidental cases
[15:45:37] --- jkwong has joined
[16:06:21] * resnick has been not keeping up with jabbering due to arguing
[16:06:58] <resnick> Argument goes on about whether we can design for intentional case alone or whether we need to design for the involuntary case.
[16:12:26] --- dbrashear has joined
[16:15:02] <resnick> So where are we?
[16:15:38] <resnick> Alexey: Current document is vague. Need to clarify text on whether we're talking about voluntary or involuntary disconnect.
[16:15:58] <resnick> We'll stick to the RECONNECT document and make changes there.
[16:17:41] <resnick> Talk about "suggested times" and whether that's a good idea.
[16:20:19] <resnick> Michael: Will put out another CLEARIDLE (with new name and no dependencies) as a proposal to address the issue.
[16:20:48] <resnick> Chair: Will be included in RECONNECT if that's how the group wants to go.
[16:25:23] <resnick> Document voluntary vs. involuntary, and remove the time limit discussion (and then we'll discuss it again once we figure out the mechanism).
[16:40:43] --- resnick has left: Disconnected
[16:41:20] --- pguenther has left: Disconnected
[16:41:20] --- hardie has left: Disconnected.
[16:41:22] --- robsiemb has left: Disconnected
[16:42:11] --- randy has left: Disconnected
[16:42:11] --- Glenn Parsons has left: Disconnected
[16:44:30] <tonyhansen> what happened? where'd everyone go?
[16:48:32] <dbrashear> network uplink died there maybe?
[16:51:35] --- randy has joined
[16:51:46] --- robsiemb has joined
[16:51:55] <robsiemb> we are back
[16:52:10] <robsiemb> we had been continuing to discuss varients on reconnect
[16:52:22] <robsiemb> one point was a discussion of the necessary scope
[16:52:35] <robsiemb> "what state are we talking about" etc
[16:52:38] <smaes> Glen's machine dropped ...
[16:53:35] <robsiemb> deadline for new documents is 21-feb, we'd like to see new documents before then
[16:53:49] <robsiemb> chairs suggest break
[17:25:41] <robsiemb> media conversion next
[17:26:56] --- pguenther has joined
[17:28:58] <robsiemb> is there anyone who things we shouldn't be working on it?
[17:29:28] <robsiemb> dave: I'm for it, but I'm sensitive to the challenges of getting it passed
[17:29:56] <robsiemb> [if anyone local can help with names, that'd be good ;]
[17:30:29] --- hardie has joined
[17:30:38] <robsiemb> chair: it is worth noting... I don't know what
[17:30:52] <robsiemb> 2 modes: streaming and non-streaming
[17:31:31] <robsiemb> hardie: do we think this is covered under the charter? -- chairs believe that this is covered under the charter
[17:31:40] --- resnick has joined
[17:31:42] <robsiemb> CHANNEL is for streaming
[17:33:06] <robsiemb> Randal: We may want to use URLAUTH instead of channel (i.e. connect to streaming server and hand it a url)
[17:33:42] <robsiemb> non-streaming would be modification of fetch to say "FETCH (stuff) (conversion info)"
[17:35:11] * resnick , having finished his banana, returns to jabbering.
[17:37:39] * resnick tries to figure out what is going on in this discussion.
[17:38:36] <robsiemb> discussion of channel conversons, there was some problem about what the client would know about the server capabilites, [but I am not sure we are sure what it was]
[17:38:46] <resnick> Michael: The server should tell the client what kinds of conversions could be done.
[17:38:53] --- dcrocker has joined
[17:40:18] <resnick> Stephane: What about the server just "knows" about the client?
[17:41:28] <resnick> Randy: That makes a very complex server.
[17:42:42] <robsiemb> pete: if this is the case, then we don't need a protocol, since the server will just hide all the details
[17:43:12] <resnick> Jerry: The server might want to offer some choices.
[17:46:00] <randy> Pete suggests that the server can synthesize choices by, e.g., presenting a body part (such as a Word document) as a multipart/alternative (eith e.g., Word, PDF, HTML, text/plain)
[17:48:07] <randy> Phil points out that the body needs to be immutable on the server, otherwise as the server configuration changes the body structure changes, confusing clients that have cached the old values
[17:49:19] <randy> Alexey suggests a CONVERT command that would convert and APPEND
[17:53:24] <robsiemb> question: can we just have a third party server do this via urlauth?
[17:54:09] <robsiemb> answer: yes, but there are pros and cons related to this (pros: imap is complex enough already / cons: we don't want to open a new session for small body parts)
[17:54:36] <resnick> If it's a conversion server, that could be a very complicated protocol (cf. OMA on transcoding).
[17:54:49] <resnick> (Sorry, that last statement was Jerry)
[17:55:07] <resnick> Randy: Maybe you don't have to be as complicated as that.
[17:56:28] <resnick> Michael: You can use out of band info to limit the protocol.
[17:56:59] <resnick> Randy: We could do a simple conversion protocol (MIME type to MIME type) and call it the 90% solution.
[18:00:40] <robsiemb> (more discussion about how to represent capabilities)
[18:05:53] <robsiemb> Pete: We need to remember the desktop clients too.
[18:07:11] <resnick> Dave: The client can inform the server of its capabilities. That's still a gain.
[18:09:52] <resnick> Randy: Server should return the answer of "what's makes sense" in order.
[18:10:15] <resnick> Others: No, that won't work, cause it will vary by "what makes sense" to who.
[18:17:16] <robsiemb> Dave: why not just use the conneg model?
[18:18:41] --- hardie has left
[18:26:23] <robsiemb> Pete: Is a mechanism where we assume the server knows all about the client and then presents all attachements as a converted mimetype good enough?
[18:27:44] <robsiemb> Pete: we could also have a client command to say "put me into helpful mode" which would blow out uidvalidities and start presenting this
[18:28:00] <robsiemb> (but it is unlikely this is what implementors really want)
[18:29:06] <robsiemb> This would not be a protocol.
[18:29:29] <robsiemb> Pete: We should assume a smart client and build protocol around that, since the server-knows-all system isn't good enough
[18:48:23] <resnick> Ted: 1. Conneg format is pretty verbose for this, so perhaps we need a shortened form.
[18:48:59] <resnick> 2. Conneg really wasn't used for http because the user is usually doing the interceding. It works in fax because the user isn't involved.
[18:52:35] --- robsiemb has left: Disconnected
[18:52:38] --- robsiemb has joined
[19:09:28] <robsiemb> Pete: is there a reason to do channel besides media conversion?
[19:09:35] <robsiemb> Chairs: Channel is dead [long live channel]
[19:10:03] <robsiemb> (because URLAUTH can be used to do most of what channel does)
[19:12:10] <resnick> Chairs: Let's get Lyndon's input into the whole media conversion discussion.
[19:12:49] <robsiemb> (or atleast we should certainly change the name)
[19:18:46] <resnick> (Discussion of STI that I don't really understand.....)
[19:20:09] <resnick> Ah: With URLAUTH, we can punt on this issue and let the client use some other protocol (like OMA's STI).
[19:21:13] <randy> Except that STI is an API not a protocol, is server-to-server, and afew other things
[19:24:06] <robsiemb> Chairs: we should check with Lyndon to see if he wants to try to morph channel to try to do this, but otherwise it should be dropped
[19:24:25] --- hardie has joined
[19:24:39] <resnick> Stephane and Alexey have started on the profile, but haven't gotten next rev out.
[19:35:29] <resnick> Administrivia about who needs to do what going on.....
[19:36:07] <resnick> SMTP Checkpoint extension and how that fits in (and if we need to re-charter to discuss it....)
[19:36:52] * resnick is slowing down in his typing abilities
[19:39:09] --- hardie has left
[19:39:35] --- smaes has left
[19:39:57] --- pguenther has left
[19:41:31] --- robsiemb has left: Logged out
[19:42:03] --- resnick has left: Disconnected
[19:42:14] --- randy has left: Disconnected
[20:06:42] --- dcrocker has left: Disconnected
[20:55:50] --- tonyhansen has left
[22:52:30] --- jkwong has left