[05:29:57] --- alexeymelnikov has joined
[06:02:36] <arnt> let's say I pressed the wrong button on my client.
[06:03:16] <arnt> modern user interfaces are so advanced that my daughter can enable modes that I can't find out how to disable.
[06:03:24] <arnt> (wasn't her this time, though.)
[07:08:32] --- kmurchison has joined
[07:31:43] <alexeymelnikov> Can somebody send me a copy of yesterday's jabber log, I lost mine...
[07:35:57] <arnt> will xml do?
[07:36:12] <arnt> oh, what I have is html
[07:37:32] <arnt> "html". it's in your mailbox.
[07:42:34] <alexeymelnikov> Arnt: Thank!
[07:43:19] <arnt> you're short of sleep, right?
[07:45:57] <alexeymelnikov> Yes, I am.
[07:46:20] <alexeymelnikov> (So I should not try to speak on the phone today)
[07:47:48] <arnt> fwiw, I have to disappear in about an hour. it's possible that I can look in again in about 5h. but I don't expect anyone to miss me.
[07:48:50] <alexeymelnikov> Arnt: we really needed your presence for VFOLDER discussion yesterday.
[07:49:44] <arnt> very sorry I couldn't be there.
[07:50:08] <arnt> until the 19th of june, I can't work full time, and my calendar is basically fucked up.
[07:51:35] <alexeymelnikov> Arnt: a question regarding WITHIN was asked. Are you Ok with allowing hour-level (or minute-level) resolution (instead of days)?
[07:53:05] <arnt> hour-level sounds okay. I think minute-level would be a problem.
[07:53:34] <alexeymelnikov> Ok. Another question:
[07:55:46] <alexeymelnikov> What is your problem with refreshing the WITHIN VFOLDERs frequently? Dave has suggested that you can sort messages by date, which can tell you when you need to check if a message drops out of the view.
[07:58:15] <arnt> I certainly could hack around it. the problem is that with current-day query planners, it's kind of hard to get both searches and near misses.
[07:58:32] <arnt> most imap servers don't use query planners. they do their searches by brute force, very slowly.
[07:58:41] <alexeymelnikov> So this is basically a problem with API you are using?
[07:59:09] <arnt> it could be, but I think it's more of a research problem for DB people. query planners don't do this kind of thing.
[08:01:01] <arnt> but I can work around it if it has to be. I can take the search tree, modify the age-based searches to be more inclusive, perform both searches, sort the messages which are in one result set by date, and do the search again at the times suggested by these messages.
[08:01:30] <alexeymelnikov> Yes, something along these lines.
[08:01:58] <arnt> that'll work okay provided the message doesn't receive too many messages per unit of time. its worst-case performance is a bit of a dog, though, so it makes vfolder scale a little suboptimally.
[08:02:09] <arnt> provided the mailbox doesn't receive, etc.
[08:03:10] <arnt> (in my world, the purpose of vfolder is to make million-message mailboxes manageable. million-message mailboxes may receive quite a few new messages per hour, so there would be quite a few refreshes.)
[08:04:20] <arnt> why do people want high-resolution age-based searches?
[08:04:42] <arnt> noone seems to miss high-resolution SINCE/SENTSINCE, etc.
[08:06:21] <alexeymelnikov> Millitary messaging (in my world, closely related to X.400 ;-)), aviation industry, etc. might need to take automatic actions if a message is not processed within minutes.
[08:07:03] <arnt> good point.
[08:08:13] <alexeymelnikov> And mail is not reliable enough for second-level resolution. (Even though in practice an implementation can be)
[08:08:31] <alexeymelnikov> I meant "not quick enough"
[08:09:30] <arnt> I hate it, but you do have a very good point.
[08:10:59] --- Glenn Parsons has joined
[08:11:45] <arnt> so I change my vote.
[08:12:04] <Glenn Parsons> I have arrived in the room and am starting to setup -- the plan is to start at 8:30am ET -- in about 20 minutes.
[08:12:13] <Glenn Parsons> I see you folks have been chatting for a while...
[08:12:40] <arnt> yes. I have to leave again, so Alexey started talking right away.
[08:25:39] --- LEMONADE has joined
[08:26:32] <alexeymelnikov> Arnt: regarding RENAME of the backing mailbox. Yesterday's consensus was that VFOLDERs should track renames of the backing mailbox. Are you Ok with that?
[08:26:43] <arnt> sure. it's what I've implemented ;)
[08:26:57] <arnt> it would be difficult for mrc to implement in uw, but I doubt he'll do that anyway.
[08:28:16] <alexeymelnikov> Ok, and DELETE of the backing mailbox should delete all attached VFOLDERs.
[08:29:49] <arnt> is also what I've implemented. I would prefer that server may defer the delete, though, but that's not a major issue to me.
[08:30:24] <arnt> e.g. the vfolder could be deleted at the time of the next status/select/examine instead of at once.
[08:32:13] <alexeymelnikov> I think it is a reasonable addition to the rule.
[08:33:40] <LEMONADE> Hmmm. There are not many people in the room yet..... just one co-chair...
[08:35:32] --- Dave Cridland has joined
[08:38:22] <LEMONADE> Will our remote participants be joining the conference bridge?
[08:39:01] <Dave Cridland> I'll be on and off it.
[08:40:24] <alexeymelnikov> I will dial in. Is there anybody else in the room?
[08:40:48] <arnt> I am dialled in.
[08:42:34] <Dave Cridland> I hear typing.
[08:44:49] <arnt> you'll see the message, too.
[08:45:55] <Dave Cridland> I'm there too.
[08:47:25] <arnt> dave, can you still hear typing?
[08:47:33] <arnt> I think I found out how to make my phone mute.
[08:48:08] <Dave Cridland> Nope. Can't hear your typing.
[08:50:07] <Dave Cridland> Still can't get the SIP thing to work.
[08:50:17] --- kmurchison has left
[08:50:43] <arnt> SIP seems like a bit of a crock to me.
[08:50:57] --- kmurchison has joined
[08:51:10] <arnt> I more or less gave up on it.
[08:51:24] <Dave Cridland> After how many RFCs?
[08:53:43] <arnt> zero point something, plus configuring an asterisk, plus helping with another, plus talking to a friend who's voip guru at a big isp here.
[08:54:10] --- eburger has joined
[08:57:22] <Glenn Parsons> STephane remembers we agreed to start at 9am :-(
[09:02:51] <Dave Cridland> Most Jabber clients have a registration function built-in.
[09:07:15] --- Jerry Shih has joined
[09:10:46] <arnt> how many people have arrived in the room so far?
[09:16:05] --- eburger has left: Replaced by new connection
[09:19:24] <Dave Cridland> Warning: Message unread for 15 minutes. Please invade Iraq.
[09:21:44] <alexeymelnikov> More important for aviation industry.
[09:23:12] --- randy has joined
[09:23:13] --- Jerry Shih has left: Replaced by new connection
[09:23:26] <arnt> alexey, explain? I mean, I don't have a problem dreaming up good uses for that. but why particularly the aviation industry?
[09:24:07] <alexeymelnikov> "Flight to Chicago got diverted. Please update you flight plan"
[09:24:35] --- Jerry Shih has joined
[09:24:36] <arnt> ack
[09:28:14] --- eburger has joined
[09:28:25] * eburger has changed the subject to: Meeting Start
[09:29:05] <eburger> Agenda: Slide 3 of Chairs' Slides
[09:29:38] <eburger> Moving OMA Liaison to after discussion of issues, so we can put together list of "near WGLC" documents.
[09:29:48] <eburger> Finish with Interoperability testing
[09:29:56] <eburger> Slide 5 - document list
[09:30:17] <eburger> Issues to be discussed on VFOLDER and WITHIN between Ray and Arnt, but Ray isn't here yet :(
[09:30:36] <eburger> Notifications, Deployments, Firewall, Streaming, and Profile is proposed order
[09:30:45] <eburger> Any bashing, or is this OK?
[09:30:56] * eburger has changed the subject to: Notifications
[09:31:08] <arnt> the meeting resumes at 13:00 ET after lunch, right?
[09:31:17] <alexeymelnikov> I think Ray, myself and Arnt are pretty much in sync on WITHIN. I can email both Arnt and Ray to confirm.
[09:31:27] <eburger> Slides are at http://www3.ietf.org/proceedings/06jul/slides/lemonade-1.ppt
[09:31:50] <alexeymelnikov> Arnt: the meeting is a half day today.
[09:32:18] <arnt> ok
[09:33:13] * eburger has changed the subject to: Back to VFOLDER
[09:33:40] <eburger> Issue: What to do about RENAME?
[09:33:56] <eburger> Arnt: happy with conclusion (tracks rename)
[09:34:26] <eburger> Issue: Append/Copy support for VFOLDER Current draft says "maybe". Alexey proposed saying "yes" unless not possible.
[09:35:00] <eburger> Arnt: Difficulty is some clients expect messages to always be there and client will repeat command if messages don't show as expected.
[09:35:14] <eburger> Arnt: would like to test proposal to see if it works.
[09:35:44] <eburger> Ray: Client can append message to folder; other client expunges message; first client says, "what happened to message?"
[09:35:56] <alexeymelnikov> I think it was Dave's comment, not mine.
[09:35:56] <eburger> Arnt: Client will retry anyway.
[09:36:20] <eburger> Propose checking implementations for this behavior before progressing to RFC.
[09:36:39] <eburger> Issue: server should be able to reject "expensive" VFOLDER requests
[09:37:21] <eburger> User Interface problem: what if request is hard-coded (not user-initiated) in the client? What could you tell the user?
[09:38:48] <alexeymelnikov> Arnt said that it is easy to add dynamic attributes to VFOLDER if CONDSTORE is already implemented.
[09:41:03] <eburger> Eric: if this comes about because client has hard-coded VFOLDER search that is too hard, then tough cookies - Joe Sixpack will go to provider and say (correctly), "the phone is broken". That will get the provider to implement 'do-able' VFOLDERs.
[09:41:44] <eburger> Consensus: since CONDSTORE is required, and Dynamic Attributes are pretty easy to implement if one does CONDSTORE, mandate both?
[09:41:59] <eburger> Especially if one does VFOLDER, too.
[09:42:47] <Dave Cridland> In Profile Bis, we can mandate both. In VMAILBOX/VFOLDER, we can't, because that should be independent of CONDSTORE.
[09:43:25] <eburger> Randy: might be 2 use cases for VFOLDERS: 1. use VFOLDERs as a notification mechanism 2. use VFOLDERs to organize large mailboxes, so not much gets cached at client.
[09:43:58] <eburger> Might be possible to have separate (static) attributes and later figure out how to work in dynamic attributes (and whether all or a fixed set)
[09:44:46] <eburger> If it is case that VFOLDERs are for two separate use cases, then we could have two behaviors (static versus dyamic).
[09:45:09] <eburger> Arnt: doesn't think they can be separated easily
[09:45:22] <eburger> Eric (as participant): complex and confusing
[09:45:34] <arnt> people want UNSEEN and "not spam" in both cases
[09:46:23] <eburger> Issue: When does the view recompute the search? Consensus: when new message comes in Other scenarios: on any IMAP command? on IMAP commands the mutate state? only on SELECT? by time interval?
[09:47:32] <arnt> I have to leave...
[09:47:36] <Dave Cridland> Personally speaking, I think "timely" is good enough, especially if there's a facility for forcing updates (like CHECK).
[09:48:23] <arnt> NOOP is that in base imap. I'm LEAVING.
[09:49:52] --- cromwellian has joined
[09:50:01] * eburger has changed the subject to: Notifications
[09:50:49] <eburger> Slide 18 of Draft Statii document
[09:52:43] <eburger> Ray had to extent EMN for our purposes; plan is to fold that back into OMA for standardization.
[09:53:05] <eburger> s/extent/extend/
[09:53:58] <eburger> Slide 19
[09:54:23] <eburger> Issue: Feature set is not orthogonal in-band vs. out-band.
[09:55:37] <eburger> Problem: MSGEVENTS, which was supposed to be an individual submission, didn't get submitted. The draft expired and is gone.
[09:56:10] <eburger> Was waiting for a review of the list of events in MSGEVENTS.
[09:58:30] <alexeymelnikov> I think Chris said he would update the document (as a WG document)
[09:59:35] --- smaes has joined
[10:05:36] <alexeymelnikov> Ned has protested again Future Delivery, not against Notifications.
[10:05:57] <alexeymelnikov> But we are planning to recharter anyway? Or at least discuss it today?
[10:07:25] <eburger> Future Delivery was a "Robert's Rules of Order" issue; Notifications was personal.
[10:08:04] <alexeymelnikov> Eric: in this case you might be better checking with Ned.
[10:08:29] <eburger> Issue: Unsolicited server responses - which ones get mapped to MSGEVENT?
[10:08:44] <eburger> Mechanism was outlined in CLEARIDLE
[10:08:49] <eburger> (dead draft)
[10:09:04] <eburger> Current NOTIFICATIONS draft says that we need to figure out this problem.
[10:09:28] <eburger> Work to be done needs to focus around in-band notifications.
[10:11:43] <alexeymelnikov> Ray said that another part of CLEARIDLE was multimailbox notifications. This can be replaced with multimailbox VFOLDERs.
[10:13:45] <alexeymelnikov> Ray is saying that he might add new "catch all response" for all events that can't map to existing IMAP responses
[10:13:54] <eburger> MSGEVENTs are not extendable (today)
[10:14:04] <eburger> Should they be?
[10:14:35] <eburger> 1. Hard 1-1 mappings 2. New unsolicited response syntax 3. Use current mappings for existing events, new stuff for new ones
[10:14:50] <mrcrispin@jabber.org> Is 3937582 still the right access code to dial in?
[10:15:12] <alexeymelnikov> Mark: yes
[10:15:18] <Dave Cridland> Mark: Yes, worked for me.
[10:15:33] <Glenn Parsons> Mark: you need # at the end...
[10:18:08] <eburger> Randy: Problem with just wakeup or IDLE: you don't know which folder generated event
[10:18:50] <mrcrispin@jabber.org> I'm entering the #, but Skype is being a pain today and apparently not sending the tones properly.
[10:19:14] <alexeymelnikov> Randy: server can return * STATUS responses for expunges/new messages in non-selected mailboxes.
[10:19:36] <randy> Alexey: I'd forgotten that
[10:20:00] <randy> How does it know which mailboxes to do this for?
[10:20:15] <eburger> Assumption is that oob notification is for when you are not connected, and ib notification is when you are connected. However, it is possible to do oob notification when connected, because it is hard to know if you are REALLY connected. Also, easier to do one implementation.
[10:21:55] <eburger> Randy: expects rules for oob notifications to be stricter than for ib notifications, because of cost (TCP versus SMS, for example).
[10:29:39] <eburger> There are clear needs to have the event set be extendable: 1. Things we don't see today 2. Things that are an anathema to the IETF, but are necessary in private IP networks, such as "LOCKDOWN"
[10:30:06] <eburger> Eric (as participant): LOCKDOWN doesn't make sense as a notification, as it MUST be outside the IMAP channel
[10:30:23] <eburger> Eric (as chair): IETF will *never* do a LOCKDOWN protocol
[10:32:18] <smaes> Does not make sense ad inband notification
[10:32:23] <smaes> as outband it may make sense...
[10:32:37] <smaes> furthermore it can be comlementary to other metods (e.g. OMA DM)
[10:33:47] <Dave Cridland> [I have to leave for a bit, back shortly]
[10:33:58] <eburger> Discussion: could use this inside IMAP, too, to flush cache for diagnostic purposes. Eric (as participant): still doesn't work inside IMAP, because the use case presumes the IMAP data base is screwed up anyway, so you would want that to happen outside of IMAP.
[10:37:16] <eburger> Randy: we should be explicit that reason #2 above (LOCKDOWN) is a very dangrous thing to do; make it explicit what kind of notifications are acceptable to go over the wire with this mechanism (stuff we don't care if it gets lost or a duplicate delivery doesn't harm anything)
[10:37:37] <eburger> Back to slide 19
[10:39:49] <alexeymelnikov> Inband notifications can be useful outside of Lemonade.
[10:40:00] <alexeymelnikov> I would slightly prefer to have 2 drafts
[10:43:56] <alexeymelnikov> I can volunteer for the inband notifications draft, if you want to do this way.
[10:44:21] <cromwellian> thats cool
[10:44:47] <eburger> Resolution: Two drafts, Alexey to help or write. Must be done by June 19.
[10:48:11] <eburger> Issue: S2S notifications do not have a binding to a protocol. Do we need to do that?
[10:52:10] <eburger> Greg: would like to have a single protocol to make life possible for IMAP server vendors
[10:54:04] <alexeymelnikov> Defining payload, have multiple protocol bindings (and define/recommend one) is fine with me.
[11:01:35] <eburger> Eric's proposal: Don't specify transport protocol for S2S in NOTIFICATIONs document. However, we WILL specify a Mandatory-to-Implement protocol for S2S in a separate document (reuse draft-ietf-lemonade-s2s?). Tie them together in profile-bis. Easy for IMAP server implementors who only want to implement single protocol. Easy for integrated vendors to chose whatever protocol they want.
[11:03:40] <eburger> Clarification: S2S protocol document should be focused in scope to messaging only.
[11:05:07] <randy> Only reason for us to do an actual protocol for notifications is to have something that is mandatory to implement in lemonade servers, and hence should be as simple and easy to implement as possible.
[11:05:11] <eburger> Randy and Stephane will edit new draft.
[11:05:32] <randy> Anything fancier can be done by other, grander protocols
[11:06:19] * eburger has changed the subject to: Deployments
[11:07:15] <Glenn Parsons> short bio-break
[11:07:30] <Glenn Parsons> We will resume on deployments in a few minutes
[11:10:14] <Dave Cridland> Ah, just in time for the break, excellent.
[11:10:22] <eburger> We're back (almost)
[11:13:20] <eburger> Dave was going to supply figures on cost of reconnection.
[11:13:39] <eburger> Zoltan suggests scrubbing Normative vs. Informative references
[11:13:42] <eburger> Need to include Notifications
[11:14:18] <Dave Cridland> Oh, yes, so I was.
[11:14:38] <eburger> Will reference RFC 4550, not profile-bis, so we can publish right away. Update (Deployments-bis) when profile-bis published.
[11:14:56] <eburger> Oops - will NOT include Notifications; put into Deployments-bis
[11:15:49] <eburger> Randy will submit new version next week, which will be directly ready for WGLC.
[11:16:01] <eburger> s/scrubbing/checking/g
[11:16:52] <eburger> Reminder: BCP
[11:17:44] <alexeymelnikov> I read Randy's draft and like it as well. Well done.
[11:18:03] <randy> Thanks Alexey
[11:18:21] <Dave Cridland> I think it's both a good and informative read.
[11:19:23] <randy> Thanks Dave
[11:19:52] <eburger> Issue: should Deployments reference TCP-challenged (informationally)?
[11:20:12] * eburger has changed the subject to: TCP Challenged
[11:20:41] <randy> And if so, should it be in this version or in deployments-bis?
[11:21:25] <randy> Ray asks if deployments should call for opening ACAP port
[11:21:27] <eburger> Slide 26
[11:21:55] <Dave Cridland> Well, I'd be happy with that, obviously.
[11:22:40] <randy> Maybe a mention wouldn't hurt?
[11:24:57] <randy> The TCP-challenged draft says:
[11:25:03] <arnt> back, sort of. will be back properly soon.
[11:25:08] <randy> . The needs of the mobile network operator community (see [MEMAIL][OMA-ME-RD]), where the reuse of an existing and well- understood technology will allow operators to apply their experience in solving practical deployment issues. Specifically, HTTP allows operators to reuse a similar setup and model that is already used for many other similar and related services, such as certain proprietary push e-mail and synchronization offerings, OMA Data Synchronization, Web services and Web access.
[11:25:33] <randy> I'm not sure what this means. What is well-understood? WHat model is being used?
[11:25:45] <eburger> Will change header from X-HTTP-Binding to something not X-
[11:28:36] <eburger> Issue: do we need to pick one of the five approaches, or just enumerate the five approaches?
[11:28:58] <eburger> Discussion: different environments may need different approaches
[11:29:50] <eburger> Randy: why have the draft (rhetorical)? because people need to deploy lemonade where TCP doesn't work. thus we should specify one and only one mechanism so we can have interoperability.
[11:30:05] <eburger> Stephane: offers that REST mapping is probably the best binding
[11:31:55] <eburger> Ray: while HTTP tunneling gives you 100% of lemonade functionality, it doesn't work in all environments
[11:37:51] <eburger> Discussion: don't want to have lemonade server vendors have to implement 6 different access protocols.
[11:38:22] --- Jerry Shih has left
[11:39:14] <randy> There seem to be two (or three) quite different environments targeted here:
[11:39:46] <randy> 1: Those where TCP can't work (some satellite systems, some set-top boxes)
[11:40:14] <randy> 2: Those where TCP could work but isn't permitted/implemented/supported (some Java environments)
[11:41:02] <randy> If we address (1), are we just setting lemonade up for big user disappointment, given that these aren't environments that support interactivity?
[11:42:04] <randy> If we address (2), are we helping things or hurting things (by enabling such environments to continue not supporting TCP even though they could, or enabling operators to continue poor TCP deployment configurations or whatever)
[11:44:50] <eburger> Discussion: Since the environment, by definition, is constrained, it makes sense to constrain what the method supports. No promises of full lemonade implmentation.
[11:45:17] <eburger> Pick the set of what works reliably, and run with that.
[11:46:00] <eburger> Glenn: document shows general mapping; separate list of "this works in this environment"
[11:46:01] <Dave Cridland> I think it's worth looking at XMPP, where there is a HTTP binding, but it's used very much as a fallback. (I think there's two, in fact).
[11:48:52] <eburger> Editorial note: don't need URL's for IETF documents; need references to _protocols_ for normative references (with URL's, if possible)
[11:50:29] <eburger> Keeping other options in document, to show why we picked REST.
[11:51:49] <eburger> REST might be a simple as a mapping from IMAP URL's to HTTP URL's
[11:52:38] <eburger> Ray will look at XMPP HTTP fall-back.
[11:53:47] <Glenn Parsons> Does an XMPP client try the XMPP port first and then fallback to HTTP binding?
[11:53:49] <Dave Cridland> I didn't mean tunnel IMAP over XMPP over HTTP, by the way.
[11:54:04] <Dave Cridland> No, most XMPP clients don't support either HTTP binding at all.
[11:54:04] <smaes> Yes i know
[11:54:41] <Glenn Parsons> But is the XMPP protocol written to imply or require that they should?
[11:54:41] <smaes> Glenn: yes
[11:55:12] <Dave Cridland> No, XMPP itself - RFC3920 - only defines a TCP mapping, but doesn't preclude any other mapping.
[11:55:38] <Glenn Parsons> and the HTTP mapping is in another RFC?
[11:55:52] <Dave Cridland> And actually, those of you on Google Talk wouldn't use it anyway, since Google has an XMPP service running on port 443 instead.
[11:56:16] --- Jerry Shih has joined
[11:56:16] <Dave Cridland> Glenn: No, the two mappings (I think) are both in JEPs - http://www.jabber.org/jeps/
[11:58:42] <Dave Cridland> JEP-0025 and JEP-0124
[12:03:36] <Glenn Parsons> lunch time....
[12:03:36] --- cromwellian has left: Lost connection
[12:03:50] <Glenn Parsons> We will resume at 1pm ET
[12:04:00] <arnt> that's in 55min, right?
[12:04:08] <Glenn Parsons> correct
[12:04:41] <eburger> If TCP-challenged does not get all lemonade features, there will be market forces to push providers and vendors to implement TCP.
[12:07:18] --- cromwellian has joined
[12:15:08] <alexeymelnikov> I've just noticed that there are several errors in chair's slides regarding content of Lemonade Profile Phase 1
[12:17:23] <arnt> as though there weren't market forces pushing people towards TCP already.
[13:00:48] --- LEMONADE has left: Logged out
[13:04:15] <eburger> We're trying to get back on the line to get to the bridge, but it sounds like there's a modem on the line (!)
[13:07:01] <eburger> Anyone here?
[13:08:24] <alexeymelnikov> I am back.
[13:08:49] <eburger> Folks are filtering down from lunch. How was dinner?
[13:09:26] <Dave Cridland> I'm in and out I'm afraid, and probably won't be on the phone bridge much.
[13:09:47] <alexeymelnikov> I didn't have mine yet.
[13:10:01] --- LEMONADE has joined
[13:10:06] <Dave Cridland> And the kids enjoyed dinner, mine's later. Lunch, on the other hand, was hours ago. :-)
[13:10:23] <alexeymelnikov> Eric: the phone bridge said that there is no chair for the conference
[13:11:02] <eburger> Alexey - do you hear a ton of static on the bridge?
[13:11:26] <eburger> Can you hear us on the bridge now?
[13:11:37] <alexeymelnikov> Yes, I can hear you now.
[13:14:41] <arnt> static, though
[13:17:08] <alexeymelnikov> Dave and myself really want to get to Profile bis.
[13:17:34] <alexeymelnikov> I am also interested in milestones & interop talk.
[13:17:59] <arnt> I'm also not anxious to spend too long. want to end work for today and cook something interesting.
[13:18:24] <eburger> Who has read the draft?
[13:18:31] * eburger has changed the subject to: Streaming
[13:18:34] <eburger> (Streaming)
[13:20:30] <LEMONADE> the draft is here
[13:20:33] <LEMONADE> http://www1.ietf.org/mail-archive/web/lemonade/current/msg02372.html
[13:21:28] <Glenn Parsons> ERic will now summarize the draft.... starting on page 4 of draft
[13:22:21] <Glenn Parsons> first draft that is an outline of the approach -- review required
[13:22:30] <alexeymelnikov> Whoever is typing on keyboard: this is really loud on the phone
[13:22:51] <Glenn Parsons> this is a SIP based approach
[13:24:09] <arnt> this is Neil Cook's first i-d, right? congratulations. rare to see a first draft so well formatted.
[13:24:28] <eburger> This does not have VCR-like controls.
[13:25:02] <eburger> Should they be included or in another draft?
[13:25:50] <eburger> Another draft for the VCR controls -- probably directed to SIPPING
[13:26:21] <eburger> Tie the two together in Profile-bis?
[13:27:03] <eburger> Greg: why is this needed....
[13:27:35] <eburger> Client cannot implement VCR controls.
[13:29:45] <greg.vaudreuil> We in Lemonade are clients of streaming tech....
[13:29:48] <arnt> the phone bridge is now useless, except as a replacement for the White Album.
[13:30:03] <greg.vaudreuil> If the standards are not mature for VCR controls... then we need to punt until they are ready.
[13:30:12] <eburger> Glenn is working on fixing the bridge
[13:30:21] <alexeymelnikov> I agree with Greg.
[13:30:22] <eburger> Standards are mature, but there are two of them :)
[13:30:39] <greg.vaudreuil> So we mandate both?
[13:30:58] <arnt> next, R2D2 will appear on the bridge.
[13:30:59] <alexeymelnikov> I would also like to see this feature to be optional for Profile bis...
[13:31:10] <alexeymelnikov> Yes, I can hear you.
[13:31:20] <mrcrispin@jabber.org> I just got hung up
[13:32:02] <eburger> We do not reference VCR controls in cook; we do a separate document on VCR controls (probably in SIP); and tie them together in Profile-bis
[13:32:29] <greg.vaudreuil> Why need a separate doc in VCR controls? There are already two.
[13:32:40] <greg.vaudreuil> What can Lemonade do here except vote for one?
[13:32:52] <eburger> exactly.
[13:33:01] <eburger> Any other issues?
[13:34:22] * eburger has changed the subject to: Profile Bis
[13:34:55] <eburger> Chairs' Slides, 21-22
[13:35:07] <alexeymelnikov> MUST implement for Phase 1 has 3 errors or so.
[13:35:14] <eburger> Draft Statii Slide 28
[13:35:17] <alexeymelnikov> Move BURL to SMTP section.
[13:35:27] <alexeymelnikov> Add NAMESPACE to IMAP sections
[13:35:45] <alexeymelnikov> And add STARTTLS to SMTP
[13:37:12] <eburger> (These are already in the Profile)
[13:37:46] <eburger> Need decisions on compression, encryption, and reconnect.
[13:37:58] <eburger> Notification stuff not resolved.
[13:38:09] <eburger> IMAP Sieve vs. VFOLDER notifications, i.e.
[13:40:08] <alexeymelnikov> We've reached decision on compression, encryption, reconned - we just need to update Profile bis.
[13:42:29] <eburger> Approach for notifications is clear (maybe cloudy)
[13:43:02] <arnt> I think I'll leave; I'm not able to follow the conversation on the phone. is there anything for which I really ought to be present?
[13:43:45] <eburger> Remove appendix on streaming and reference Cook draft
[13:44:03] <eburger> Is Streaming a MUST?
[13:45:12] <eburger> Ray: URLAUTH does not specify conversion. how do we do it?
[13:45:24] <alexeymelnikov> Profile bis is getting quite complicated even if Phase 1 is implemented.
[13:45:48] <alexeymelnikov> So I would rather make streaming optional.
[13:45:49] <eburger> Answer: media server does media conversion for you (by design)
[13:46:48] <greg.vaudreuil> Original decision was that optional was bad in Lemonade.... However, streaming applies to client which may pick and choose.
[13:47:02] <eburger> On the "is streaming required" question: streaming is NOT a server feature
[13:47:19] <greg.vaudreuil> Message store is not involved in streaming.... streaming server is. So, a streaming server is lemonade compliant if it can handle a URLAUTH
[13:47:33] <eburger> The server needs to support URLAUTH, which it does anyway for forward-without-download
[13:47:55] <greg.vaudreuil> So, we have a third entity to which we have applicability. IMAP server, Client, and streaming server
[13:48:03] <eburger> The client can chose to implment the standard use of a streaming server, using Cook
[13:48:31] <greg.vaudreuil> Yes, everything is optional for the client, includign streaming
[13:50:24] <eburger> Greg: Need to determine location of streaming server
[13:50:32] <eburger> Neil is working on that.
[13:50:41] <alexeymelnikov> I agree with Greg.
[13:50:44] <eburger> (part of Cook)
[13:51:09] <eburger> Or, does it belong in Profile-bis?
[13:51:46] <greg.vaudreuil> Maybe this is a lemonade IMAP server capability... just indicating the identity of a streaming server available for such servcies
[13:51:56] <eburger> That is the direction where Neil was going.
[13:51:59] <alexeymelnikov> Discoverability belongs to Profile-bis, IMHO.
[13:52:08] <eburger> I can live with that.
[13:52:30] <greg.vaudreuil> There is an administrative relationship between streaming server and IMAP server....
[13:53:49] <eburger> Not necessarily...
[13:55:33] <eburger> Resolution of how to determine media server location: Neil will send text for inclusion in Profile-bis. As a stop-gap, he can put it into an appendix of Cook and we'll move it later.
[13:57:10] <alexeymelnikov> We can publish a new Profile bis and people can complain if they don't like some choices.
[13:57:18] <eburger> We will review MUST implments on the mail list.
[13:57:21] <alexeymelnikov> Or we can discuss it upfront on the mailing list.
[13:57:32] <eburger> And, yes, the best way to get comments is to publish Profile-bis
[13:57:43] * eburger has changed the subject to: OMA Liaison
[13:57:56] <greg.vaudreuil> Are there any "may" implements? I thought everything was "must" in the profile
[13:58:14] <alexeymelnikov> Greg: In Phase 1 everything is a MUST
[13:58:38] <greg.vaudreuil> different in bis?
[13:58:55] <alexeymelnikov> Greg: I don't know yet. Depends on feedback.
[13:59:24] <greg.vaudreuil> no audio from room?
[13:59:42] <alexeymelnikov> No, can't hear any audio from the room.
[13:59:53] <alexeymelnikov> I can hear you now.
[14:00:29] <eburger> Which documents are ready for WGLC?
[14:01:05] <alexeymelnikov> Cyrus' METADATA (per mailbox/per user annotations) is a dependency for Phase bis.
[14:01:14] <alexeymelnikov> Even though it is not a WG document.
[14:01:30] <eburger> FUTUREDELIVERY, RECONNECT, CONVERT, WITHIN
[14:01:41] <alexeymelnikov> But I am wondering if it should be informally last called in the WG.
[14:01:45] <eburger> Is METADATA ready for IETF LC?
[14:02:21] <alexeymelnikov> I think METADATA is ready, but I haven't checked it recently.
[14:02:47] <greg.vaudreuil> futuredelivery is already WGLC'ed.... in IETF LC
[14:02:58] <eburger> (right)
[14:03:50] <alexeymelnikov> ESEARCH (another dependency for Phase bis) is also ready for IETF LC.
[14:04:07] <eburger> DEPLOYMENT
[14:04:27] <alexeymelnikov> BTW, what is the state of BINARY?
[14:04:39] <alexeymelnikov> (IMAP BINARY)
[14:05:45] <eburger> COMPRESS is not ready, VFOLDER is not ready
[14:06:19] <eburger> Streaming is not ready
[14:06:23] <alexeymelnikov> We have enough documents ready for WGLC.
[14:06:24] <Dave Cridland> Alexey: I've not heard anything from Lyndon, but he was going to be doing an update to BINARY.
[14:06:43] <alexeymelnikov> Need to kick Lyndon.
[14:06:54] <Dave Cridland> Alexey: I tried to cope without it in Profile Bis by the "MUST support a BINARY APPEND" text, but really it needs to cope with CATENATE etc.
[14:07:02] <eburger> S2S protocol is not written, so not ready :)
[14:07:19] <Dave Cridland> Eric: We could still mandate it, to see if anyone's paying attention.
[14:07:54] <alexeymelnikov> I don't want to have more than 1 document in WGLC at any given time, it takes time to review documents.
[14:08:42] <eburger> Bridge fixed; ADSL filter installed.
[14:09:40] <eburger> FUTUREDELIVERY, RECONNECT, CONVERT, WITHIN, METADATA, ESEARCH, DEPLOYMENT are the drafts ready for WGLC/IETF LC
[14:11:14] <alexeymelnikov> ESEARCH is draft-melnikov-imap-search-ret-02.txt, but it might have expired. I will need to do a quick revision anyway.
[14:11:50] <alexeymelnikov> Please don't have more than 1 WGLC in progress at any give time.
[14:12:25] <eburger> The plan is to stagger them.
[14:12:31] <alexeymelnikov> Thanks.
[14:13:12] <Dave Cridland> RECONNECT is ready? Or do you mean now-Experimental server-state one?
[14:13:31] <eburger> Oops! RECONNECT is *NOT* ready
[14:13:32] <alexeymelnikov> RECONNECT is kind of ready.
[14:13:41] <cromwellian> i think we need to have discussion on perhaps an optional opaque token
[14:13:51] <alexeymelnikov> I will do a quick revision of server side reconnect, which would be ready.
[14:13:54] <cromwellian> for the client to store and ask the server top generate
[14:14:27] <Dave Cridland> Ray: You'd be happy if we can prove it can be added safely later?
[14:16:01] <cromwellian> ill discuss with stephane. im concern if millions of clients implement a fixed client-side state exchange, that when we add the optional state-preserving (marshalled server state) token later, it probably won't be picked up.
[14:16:58] <Dave Cridland> Ray: If clients have the opportunity to get the server to do more work for them, they tend to take it up pretty quick. CHILDREN is one example.
[14:17:20] <eburger> Optics of putting server-based RECONNECT on WGLC and than abandoning it would be BAD
[14:17:22] <cromwellian> i gotta run to airport, but ill email alexey and dave later and we can have offline discussion. Since I can't think of any additional server state right now, im am semi-ambivalent
[14:17:46] <alexeymelnikov> Guess
[14:17:59] <alexeymelnikov> Server side reconnect: me + Corby
[14:18:05] <Dave Cridland> Okay. Or via XMPP/Jabber is fine.
[14:18:06] <alexeymelnikov> Client side: me + Corby + Dave
[14:18:12] <cromwellian> ok
[14:18:21] <eburger> From the Minutes: Create new document centered around client-driven RECONNECT. It will be a work group document: draft-ietf-lemonade-reconnect-client; we are confident in its status as only about 2 paragraphs change. After the new draft is issued and the old draft is updated (there are some ABNF issues, etc. that need to be addressed), we will preferably chose one document and kill the other. Alternately, we will chose one, reference it in Profile-bis, and release the other as Experimental. Worst-case is both documents progress.
[14:18:30] --- cromwellian has left
[14:19:07] <greg.vaudreuil> gregv signing off.....
[14:19:44] * resnick will be back later
[14:21:09] <eburger> (search-ret is expired, Alexey)
[14:21:17] * eburger has changed the subject to: Interop Testing
[14:22:19] <Dave Cridland> [BTW, I'm off audio, sorry, I need to keep the phone free, so please keep this room active...]
[14:23:05] <alexeymelnikov> Interop test forward without download?
[14:24:35] <Dave Cridland> Well, I have a full trio client-side implementation that's quite easily scriptable, and GPL licensed, if this might help.
[14:26:12] <alexeymelnikov> Should we also test each SHOULD/MUST statement in the trio?
[14:26:45] <Dave Cridland> I'm happy to personally test every SHOULD or MUST in CATENATE in anyone's implementation.
[14:27:07] <alexeymelnikov> Dave: yes, that indeed would be a good idea.
[14:27:11] <Dave Cridland> (Since it has none...)
[14:27:48] <alexeymelnikov> :-)
[14:28:10] <alexeymelnikov> Dave: then do URLAUTH, that would keep you busy for a while
[14:28:37] <Dave Cridland> But in all seriousness, testing every SHOULD and MUST case generally involves writing a fairly complex and involved test suite, which in turn has to operate correctly, and other WGs have fallen into severe strife trying to agree whether the test suite is correct or not.
[14:29:25] <alexeymelnikov> IMC Mailconnect for quite useful for IMAP and SASL testing.
[14:29:47] <alexeymelnikov> But it never had an official test suite
[14:30:05] <Dave Cridland> So I would argue that while interop testing is generally good, and I'm perfectly happy to do that, doing conformance testing is something that I'm happy to leave alone.
[14:32:03] <alexeymelnikov> Yes, conformance can be tricky if there are multiple implementations options. But we still need to check all MUSTs/SHOULDs
[14:33:28] <LEMONADE> Reasons for Interop Marketing Moving to IETF Draft standard Compliance Conformance PICS Interop test suite Input to OMA IOP
[14:34:01] <eburger> Private testing venues: I want to do that where there is a preponderance of ENGINEERS (not marketeers), e.g.: California (Qualcomm, Sun, Oracle, WU), or UK (Dave, Arnt (closer), isode, Comverse (closer))
[14:34:28] <LEMONADE> Venue opportunities Private testing UK or California or ? Fall 2006 Telecom 2006 Hong Kong Dec 4-8 3GSM 2007 Barcelona Feb 12-15
[14:37:45] <alexeymelnikov> So when approximately is the private testing?
[14:37:49] <arnt> I could go to the UK for some interop testing. not sure I'd bother to go to the US, until the visa application procedure is streamlined.
[14:38:16] <alexeymelnikov> Should we replace next Interim with private testing event?
[14:38:19] <Glenn Parsons> Fall 2006 is my thinking
[14:38:24] <Glenn Parsons> for private testing
[14:38:56] <alexeymelnikov> Fall is not a month. September versa October might make a difference for me personally.
[14:39:04] <eburger> Glenn is referring to the "Conformance / Interoperability" link found at http://www.vpim.org
[14:39:50] <eburger> No automated test suite
[14:40:44] <alexeymelnikov> Well, some things can be automated. I think we need to discuss on case by case.
[14:40:59] <eburger> Send in your preference for when to have the Private Testing
[14:41:05] <eburger> (to the list)
[14:41:23] <Dave Cridland> I have to go, I'm afraid, but basically I can do remote interop whenever and wherever, for face-to-face, UK or Europe would be better. I'm unconvinced they'll currently let me into the US. I can do some basic scripted tests, too. And obviously I can do Lemonade Profile 1 tomorrow, time-wise.
[14:41:26] <alexeymelnikov> I am busy before September 14. Otherwise no plans.
[14:41:42] <eburger> excellent
[14:43:43] <arnt> London, sometime in October would be fine, not?
[14:43:53] <eburger> Our "proposal" to the OMA is that we have an interoperability event at 3GSM
[14:44:00] <mrcrispin@jabber.org> arnt and Dave: can't you get in on visa waiver? Conferences fall in under the exception.
[14:44:20] <alexeymelnikov> London in October would be fine with me.
[14:44:22] <eburger> How is October 23 - 27 in London?
[14:44:31] <eburger> (to be specific)
[14:44:48] <arnt> mark: I can't apply here. I can get in easily enough, but applying involves an overnight trip, and I'm arrogant enough to not do that.
[14:45:01] <alexeymelnikov> In theory we can have simultaneous event in 2 locations (just an idead)
[14:45:15] <arnt> oct 23-27 is fine, say I.
[14:45:16] <alexeymelnikov> But face-to-face in one place would be best
[14:45:39] <alexeymelnikov> October dates look fine to me.
[14:48:08] <arnt> I would apply if I could apply in the consulate that's across the street from one of my favourite restaurants.
[14:48:14] <mrcrispin@jabber.org> arnt: why do you have to apply at all? Isn't there a visa waiver?
[14:48:41] <alexeymelnikov> Arnt: you just need to have machine readable passport.
[14:48:48] <arnt> the old visa waiver was cancelled, at least for my case.
[14:48:56] <alexeymelnikov> Arnt: I tend to agree with Mark.
[14:49:00] <arnt> alexey: getting such involves going to norway and applying there.
[14:49:56] <alexeymelnikov> We need to prepare for the event in advance anyway. Get hardware, discuss test plan, etc.
[14:50:41] <arnt> there was a program whereby I'd apply for a visa at the airport and it would be granted on the spot. small, simple form to fill in. but later (after the last time I visted the US) that program was restricted to some class of norwegians to which I do not belong.
[14:51:18] <eburger> Interop testing "Organized" by EIMG group
[14:51:29] <alexeymelnikov> London is obviously fine with me, but I can go to US.
[14:51:42] <eburger> s/Organized/Facilitated
[14:51:50] <arnt> alexey, dinner at the River Café after interop? ;)
[14:52:26] <mrcrispin@jabber.org> arnt: the US State Department website http://travel.state.gov/visa/temp/without/without_1990.html says that Norway is part of the visa waiver program.
[14:52:32] <mrcrispin@jabber.org> you just need a machine readable passport
[14:53:07] <arnt> mark, yes, but _I_ cannot get a machine readable passport without visiting oslo, so in my case that's not actually an improvement.
[14:53:36] <eburger> Arnt - where *are* you?
[14:53:50] <alexeymelnikov> Arnt is in Germany
[14:53:51] <arnt> mark, I'm an expat. I live in Germany. can we stop discussing me and talk about interop?
[14:55:08] <eburger> As a reminder, we are doing the Private Testing to (1) prove accuracy / viability of IETF I-D's before RFC publication and (2) Moving toe IETF Draft Standard from Proposed standard
[14:57:57] <alexeymelnikov> Will Sheward from Isode can participate in marketing effort.
[14:58:03] <eburger> Excellent.
[14:58:28] <alexeymelnikov> Eric: Did Will contacted you recently about Lemonade?
[14:58:35] <eburger> Yes - I need to read the e-mail :)
[14:58:46] <alexeymelnikov> Please do.
[15:00:24] <eburger> OMA Liaison: tell them we're doing the Private Testing, and why; we are trying to organize event at Telecom, and why; and that we would like to do an event at 3GSM.
[15:03:18] <eburger> Glenn will write up OMA Liaison and post to list.
[15:03:42] <eburger> SHORT fuse: need to have finished and approved by *THIS SUNDAY*
[15:05:45] <eburger> Next meeting, IETF 66; requested 2 sessions of 2 hours, separated by a day.
[15:06:28] <alexeymelnikov> Interop and interim would be too much, IMHO. Just have one, maybe combine them.
[15:06:40] <eburger> Agreed
[15:07:04] <randy> Good idea Alexey
[15:07:55] --- randy has left: Logged out
[15:07:57] <eburger> Meeting finished
[15:07:57] <Glenn Parsons> We are done
[15:08:06] <Glenn Parsons> Thanks everyone for participating!!!
[15:08:22] <alexeymelnikov> See you.
[15:08:33] --- Jerry Shih has left
[15:08:36] <Glenn Parsons> THanks to Nortel for hosting :-)
[15:08:44] --- smaes has left
[15:08:57] <mrcrispin@jabber.org> sayonara
[15:09:03] <alexeymelnikov> Thanks.
[15:09:06] --- alexeymelnikov has left
[15:09:26] --- arnt has left
[15:09:38] --- eburger has left
[15:10:10] --- resnick has left
[15:10:39] --- mrcrispin@jabber.org has left: Logged out
[15:28:47] --- kmurchison has left
[15:29:39] --- cromwellian has joined
[15:33:45] --- Glenn Parsons has left
[15:37:41] --- cromwellian has left
[15:45:59] --- LEMONADE has left: Logged out
[15:58:49] --- eburger has joined
[16:26:45] --- eburger has left
[19:27:17] --- Dave Cridland has left