[08:21:44] --- kmurchison has left
[09:10:58] --- Glenn Parsons has joined
[12:02:03] --- LOGGING STARTED
[12:04:19] --- greg.vaudreuil has joined
[12:13:54] --- arnt has joined
[12:30:14] --- pguenther has joined
[12:40:07] --- fanf has joined
[12:50:54] <arnt> phillip, will you be scribe again?
[12:54:46] <pguenther> oh please no
[12:54:51] <pguenther> have pity on me, man!
[12:57:13] --- cnewman has joined
[12:57:32] --- NFreed@jabber.org has joined
[12:58:38] <arnt> but perhaps you can poke me a little if you think I ought to appear soon? I'm dog tired from a long flight and don't want to sit here for two hours.
[12:58:55] --- lemonade has joined
[12:59:37] --- leiba has joined
[12:59:50] <pguenther> sure
[13:00:35] --- tonyhansen has joined
[13:00:39] --- cromwellian has joined
[13:02:08] <pguenther> Ned?
[13:02:21] --- frodek has joined
[13:02:56] <NFreed@jabber.org> Yes?
[13:03:17] <lemonade> let us begin
[13:03:29] <pguenther> was my note about the non-UTF8 strings for 3028bis close?
[13:03:50] <NFreed@jabber.org> Sorry, haven't gotten to it yet. I'll take a look here in a minute.
[13:05:08] <pguenther> thank you
[13:05:52] --- eburger has joined
[13:06:08] <eburger> How's the audio?
[13:06:17] <cromwellian> good
[13:06:17] <leiba> Comment?
[13:06:28] <eburger> Well, thank you :)
[13:06:29] --- smaes has joined
[13:06:43] <tonyhansen> blue sheet, note well
[13:06:52] --- resnick has joined
[13:07:15] --- Mike Parsel has joined
[13:07:42] <tonyhansen> audio feed changed from yesterday
[13:07:54] --- 力颯 has joined
[13:07:57] <resnick> Channel 4 today
[13:08:09] <tonyhansen> videolab.uoregon.edu/events/ietf/ietf668.m3u
[13:08:17] <tonyhansen> and 664.m3u
[13:08:25] <resnick> 664 is today.
[13:08:54] <resnick> ietf66-ch4
[13:09:10] <tonyhansen> agenda files were updated from yesterday to reflect yesterday's reality
[13:09:14] <pguenther> arnt, which items are you most concerned with?
[13:09:27] --- alexeymelnikov has joined
[13:09:31] --- hardie@jabber.psg.com has joined
[13:09:43] <resnick> And anyone else in later timezones...
[13:09:46] --- cyrus_daboo has joined
[13:10:03] --- hardie@jabber.psg.com has left
[13:10:14] * pguenther nudges arnt
[13:10:56] <tonyhansen> reconnect is first
[13:11:46] --- tlr has joined
[13:12:56] <tonyhansen> zoltan's(?) issue: client should always try to reconnect
[13:13:11] --- Glenn Parsons has joined
[13:13:31] <tonyhansen> phil: comment about similiarity to ??, will bring up on list
[13:13:47] <eburger> ?? = TLS
[13:13:51] <tonyhansen> alexey: new doc on client side
[13:14:08] --- tlr has left
[13:14:40] <pguenther> TLS session resumption is requested by client; server says no-go if it's expired the session state
[13:15:12] <pguenther> no provision for extending lifetime of session state, etc
[13:15:31] --- ⎈ has joined
[13:15:44] <tonyhansen> eric: what would client do other than resync
[13:16:13] <tonyhansen> avoid issues w/ large mailboxes
[13:16:46] <tonyhansen> cyrus: let uidvalidity handle it and fall back to current semantics
[13:17:09] <pguenther> let the client decide whether it wants to bury its link in new data
[13:17:12] <tonyhansen> issue 2: depend on expunge extension
[13:17:26] * pguenther renews his nudge of arnt
[13:17:26] --- Randall Gellens has joined
[13:18:23] <tonyhansen> barry: what about uidplus and how it handles expunge?
[13:18:50] <tonyhansen> alexey: that's ok
[13:19:36] <tonyhansen> dave needs to make his argument about expunge
[13:19:49] <tonyhansen> which do we want: server side or client side?
[13:20:03] <Randall Gellens> Cyrus, are you saying that if the session expired the server should change uidvalitity?
[13:21:19] <tonyhansen> glenn: require one and other optional? or pick one?
[13:21:24] <cyrus_daboo> No - I was only addressing the case where the uidvalidity had already changed for whatever reason.
[13:21:47] <tonyhansen> glenn: document both, then require one in lemonade profile?
[13:22:03] <cromwellian> the only pro of server is future expansion of state being remembered I think
[13:22:31] <arnt> phillip, thanks.
[13:23:09] <cromwellian> i think client side is more elegant/efficient
[13:24:18] <cromwellian> could the client be surprised tho if the server remembered state, if it assumed the server didn't?
[13:24:24] <pguenther> arnt: we'll flip over to whatever you want to talk about once reconnect is done
[13:24:35] <tonyhansen> eric: put a stakethrough server side
[13:25:11] <cromwellian> shouldn't we atleast inform clients of the possibilities of servers using the sessionid to remember state?
[13:25:16] <arnt> I have no particular desire... but if anyone wants to talk about compress, I'd better be here, and views, too, hadn't I better be here?
[13:25:27] <cromwellian> definately arnt
[13:25:55] <tonyhansen> glenn: let it expire? publish as info? etc. phil: keep it with discussions about why this is a bad idea
[13:27:04] <tonyhansen> alexey: may still need it glenn: put it on back burner? eric: channelling ray
[13:29:14] <tonyhansen> eric: put text in client doc saying why server side is bad glenn, stephan: put text in lemonade profile hum time?
[13:30:36] <tonyhansen> stephan? do we add text to profile or not? clarifying what text would be: why client vs server, and server can still maintain state
[13:31:00] <eburger> Resolved: this text goes into Profile-bis
[13:31:25] <tonyhansen> everyone needs to review reconect-client now
[13:31:41] <cromwellian> quick question alexey, lets say a server implements CONTEXT, will resuming a session resume all the CONTEXTs that are active with NOTIFTY?
[13:31:55] <eburger> Reconnect client is a drafty draft. Need to look closely at next draft.
[13:32:04] <cromwellian> or will the client need to reissue all the CONTEXTs?
[13:32:33] <cromwellian> someone channel me :)
[13:33:09] <tonyhansen> alexey: yes
[13:33:12] <resnick> Hear that, Ray?
[13:33:16] <cromwellian> yep
[13:33:19] <tonyhansen> client would need to reissue contexts
[13:33:27] <tonyhansen> stephan: does that change anything?
[13:33:42] <tonyhansen> alexey: not really;
[13:33:44] <cromwellian> ok, some some servers might want to advertise server side state? perhaps so clients will know that they don't have to reissue? is there a way for a client to know what to do?
[13:33:51] <tonyhansen> also other missing text
[13:34:08] <tonyhansen> stephan: might to wait yet on killing server side
[13:34:09] <cromwellian> im curious how a client knows if the server is remembering state or not so it can avoid resending it
[13:34:44] <cromwellian> ok, thanks eric :)
[13:34:55] <eburger> No problem (6)
[13:35:28] <tonyhansen> eric/glenn: changing mind about what goes in profile: go to pros/cons and then decide
[13:35:56] <tonyhansen> stephan: questions
[13:36:08] <tonyhansen> glenn: need to look for gotchas in picking client
[13:36:31] <cromwellian> there is also context
[13:36:46] <cromwellian> context and vfolder are the two overlapping view proposals
[13:36:59] <tonyhansen> on to compress
[13:37:01] <tonyhansen> arnt?
[13:37:06] <cromwellian> is dave here?
[13:37:06] <arnt> I'm here
[13:37:14] <arnt> I have sound, too, but it seems silent atm
[13:37:19] <Glenn Parsons> what are the issues?
[13:37:57] <arnt> either dave, ray or I could, I guess. probably we'd say much the same things.
[13:37:59] <eburger> Tony: does the dictionary grow without bound, or is it constrained?
[13:38:00] <cromwellian> maybe you can look at the mailing list, I think randy's messages might sum them up
[13:38:29] <fanf> dave said on the list that deflate's memory requirements are mostly constant
[13:39:05] <tonyhansen> phil: chanelling randy's comments
[13:39:09] --- xiaodong has joined
[13:39:28] <arnt> dictionaries don't grow.
[13:40:44] <arnt> than 64k?
[13:40:45] <cromwellian> if cpu is a problem, client can control compression rate and lower it?
[13:41:54] <tonyhansen> phill: thinks everything is satisified: can we ship it?
[13:42:05] <tonyhansen> arnt? any other issues?
[13:42:08] <arnt> we can ship. only editorial stuff left.
[13:42:24] <arnt> (since randy's most helpful and authoritative answers.)
[13:42:55] <tonyhansen> glenn? two direction negotiation?
[13:42:58] <arnt> I can submit a new revision with the typos and so on done, then we do WGLC when the i-d editor is back on the job.
[13:43:34] <tonyhansen> eric: remove ability to specify both directions? simplify?
[13:43:44] <tonyhansen> yes, simplify
[13:44:02] <tonyhansen> and compress both ways always?
[13:44:22] <tonyhansen> hum? up and down both, vs separate
[13:45:11] <tonyhansen> ted: clarifying hum
[13:45:25] <cnewman> hmmmm for simpler option
[13:45:30] <greg.vaudreuil> hmmmm
[13:45:38] <NFreed@jabber.org> I'm pretty much convinced that simpler is better.
[13:46:07] <arnt> hmmmmm for simpler (of course)
[13:46:09] <tonyhansen> hum for simplifing (compress both ways always)
[13:46:35] <arnt> more complex -> more to do i14y testing for
[13:47:03] <fanf> microphone please
[13:47:33] <tonyhansen> ted: explaining why separating would be useful: future cases
[13:48:02] <cnewman> I prefer to not compress the word interoperability and let the transport compression do the work. :-)
[13:49:05] <tonyhansen> concensus for simple
[13:49:19] --- Dave Cridland has joined
[13:49:28] <tonyhansen> on to vfolder
[13:49:45] <arnt> I shall post the new compress i-d tomorrow. (the i-d editor isn't back of course.)
[13:50:08] <⎈> yes; you can post new i-ds now.
[13:50:15] <tonyhansen> actually, I-D editor is on the job again
[13:50:17] <⎈> They start again at the beginning of IETF week
[13:50:31] <Dave Cridland> [Apologies for lateness, prior engagement with children's bedtime]
[13:50:37] <cromwellian> these were all consensus agreements from interrim
[13:51:18] <cromwellian> there is also a debate between implementors over how bad it is to store extra state needed to handle assigning new UIDs
[13:51:36] <tonyhansen> stefan: covering interim consensus; new draft covers them
[13:51:40] <cromwellian> arnt implemented it, I think he didn'tt have too big of a problem, but Curtis King didn't like it.
[13:51:45] <cnewman> Is ⎈ the geek formerly known as prince?
[13:51:56] <tonyhansen> glenn: only new issue is one posted to list yesterday
[13:52:19] <tonyhansen> stefan: multiple mailboxes doesn't matter
[13:52:25] <cromwellian> having a search that operates over multiple mailboxes in your folders on a single imap server
[13:52:45] <⎈> cnewman: I was just jealous of 力颯
[13:53:03] <cromwellian> no, it is on a single server Glenn
[13:53:06] <cromwellian> same imap server
[13:53:39] <cromwellian> same user
[13:54:05] <cromwellian> i suppose for shared public folders it could be used too
[13:54:10] <tonyhansen> stefan: agrees
[13:54:11] <力颯> Check here for your own name transliterated: http://chineseculture.about.com/library/name/blname.htm
[13:54:38] <cromwellian> lisa? was that a paste in the wrong window? :)
[13:55:11] <cromwellian> its a virtual mailbox that searches all of your OWN mailboxes on your imap server
[13:55:37] <力颯> Somebody was jealous of my transliterated name, so that wasn't a mispaste, though I'll quit the offtopic now.
[13:57:07] <Dave Cridland> What actually concerns me most of all about virtual mailboxes is that there appears to be no consensus on the list that virtual mailboxes are safe to expose to ordinary clients or not. If they are, that's a pretty compelling argument for them.
[13:57:08] <cromwellian> no prob. btw, what is it (your chinese name)
[13:57:25] <tonyhansen> glenn asks clarifying ?s about single mailbox
[13:57:52] <tonyhansen> stefan will clarify in profile
[13:58:01] <cromwellian> i suspect it will probably have to be hashed out offline
[13:58:38] <tonyhansen> eric channels dave
[13:58:43] <arnt> dave, I haven't had any negative reports, but surely, if the things are widely used some MUA somewhere will have a problem.
[13:59:00] <tonyhansen> stefan: exposing may have value, but has issues
[13:59:17] <tonyhansen> stefan: possibly useful outside lemonade profile?
[13:59:28] <cromwellian> arnt, in your opinion, how common is it, that UIDs get reissued, e.g. cause legacy clients o download duplicates
[13:59:28] <tonyhansen> on to context
[13:59:35] <cromwellian> if it is very rare, then I dont see the problem
[13:59:45] <tonyhansen> eric will channel dave
[13:59:48] <tonyhansen> dave?
[13:59:49] <eburger> dave: any issues for me to bring up about CONTEXT
[14:00:01] --- resnick has left
[14:00:23] <arnt> ray: I've never seen it in practice... but I think there are cases where it would happen. primarily when annotations are used in the search expression.
[14:00:39] <Dave Cridland> Not really. Most of the comments I've had have been about whether virtual mailboxes were better or not.
[14:00:41] <arnt> oh wait. I've seen it when the search expression changes.
[14:00:50] <cromwellian> my issue with context is I would prefer that context specifies how to name contexts and enumerate them so that they can be shared wirth other clients (perhaps using METADATA)
[14:00:51] <Dave Cridland> That and the lack of examples, etc.
[14:01:14] <Dave Cridland> Ray: I think that's an orthogonal issue. I can put that in the same draft, of course.
[14:01:19] <cromwellian> transient is the word stephane is searching for
[14:01:20] <tonyhansen> stefan: vfolder caters to oob context is more transitional
[14:01:30] <tonyhansen> stefan: they're complementary
[14:01:33] --- resnick has joined
[14:02:01] <tonyhansen> alexey: we need a doc on how to manage filters, named filters
[14:02:13] <tonyhansen> alexey: tie in to notifications
[14:02:13] <cromwellian> exactly alexey
[14:02:17] <Dave Cridland> I think using vfolder for notifications is really a matter of shifting the problem. Basically you're designing a "whole mailbox" notification system, then you're building a method to alter the mailbox to fit the need.
[14:02:50] --- ⎈ has left
[14:03:05] <Dave Cridland> Contexts assumes that notification filters, viewing filters, etc need not precisely match.
[14:03:10] <cromwellian> I think for out of band, the issue is, what is the language used for notifications? is it sieve or is it imap search? I woudl argue that search programs are read/write, sieve is write only, and search is easier to build a UI
[14:03:15] <tonyhansen> alexey: was 50/50 between the two
[14:03:28] <tonyhansen> eric channels dave
[14:03:32] <cromwellian> context and vfolder both use search as the filtering language, only difference is, contexts are not persistent
[14:04:16] <tonyhansen> and ray
[14:04:38] <cromwellian> well, thats not the only different :)
[14:05:18] <alexeymelnikov> Ray is correct, but it is not the *only* difference
[14:05:50] <cromwellian> i would point out that the notifications draft does not use "whole mailbox" notification, VFOLDER is applied first (view filter), then a notification filter is applied afterwards
[14:06:19] <tonyhansen> stefan: (boiled down) persistence is critical
[14:06:45] <Dave Cridland> Hmmm... So if you AND the view filter and the original notification filter, use that as the new notification filter, what's the difference?
[14:07:08] <cromwellian> the notification filter may or may not exist on the imap server
[14:07:13] <cromwellian> it might be on the magic notifications box
[14:07:44] <tonyhansen> phil: vmailbo can be synchronized against
[14:07:51] <Dave Cridland> (Incidentally, I still cannot get audio without massive amounts of break-up)
[14:08:19] <cromwellian> i dont think we have decided where the NF lives yet
[14:08:31] <tonyhansen> phil: clients will want to use vmailbox directly
[14:08:33] <Dave Cridland> Yes, you can use traditional synchronization techniques against a virtual mailbox.
[14:08:37] <arnt> Dave Cridland: I have fine audio.
[14:09:11] <Dave Cridland> Arnt: I can't get the MP3 to come down the line quick enough. It's not a local issue.
[14:09:16] <cromwellian> I will add that I like context, and there is no reason why it can't be combined with vfolder, or some other technique for out of band
[14:09:16] --- ⎈ has joined
[14:09:54] <tonyhansen> glenn: seems that vfolder better meets criteria. Is there useful stuff from context that could be folded in?
[14:10:02] <arnt> I too kind of like vfolder... I have some strong dislikes, but I also kind of like it.
[14:10:06] <tonyhansen> eric: channels ray
[14:10:16] <cromwellian> they are not neccessarily adversarial, context is a nice optimization for running lots of searches on its own
[14:10:25] <cromwellian> also, it provides an in-band notification mechanism
[14:10:34] <tonyhansen> stefan: concurs that useful things in both
[14:10:38] <Dave Cridland> Oh, I *like* virtual mailboxes. Although I think they'd be *so* much more interesting with multiple mailboxes backing them.
[14:10:52] <alexeymelnikov> If I remember Curtis argument correctly: one needs to show VMailboxes differently in UI, as there are some semantical differences between mailboxes and vmailboxes. This means that vmailboxes can only appear in extended LIST. Plus vmailboxes have issues with messages reappearing in the middle of the mailbox. If we get rid of the mailbox semantics for vmailboxes, we end up doing contexts.
[14:11:00] <alexeymelnikov> I hope this makes sense.
[14:11:14] <cromwellian> I like multiple backing mailboxes too, I fear the arguments on saving state on servetr tho, since it would appear every message would need a new UID
[14:11:21] <Dave Cridland> I'm just convinced by the server implementors that say it's difficult, and I'm concerned by the varying arguments for and against making them appear to naíve clients.
[14:11:28] <tonyhansen> eric channels jabber
[14:12:30] <tonyhansen> cyrus: concerned about how mobile clients will create these things
[14:12:55] <tonyhansen> cyrus: particular with naming interop
[14:12:59] <fanf> (sounds ilke the trash mailbox problem)
[14:13:05] <tonyhansen> (yup)\
[14:13:19] <tonyhansen> stefan: is there a proposal to fix it?
[14:13:33] <cromwellian> maybe we need to dispense with mailboxes totally, and just use ANNOTATE to tag categories :)
[14:13:47] <tonyhansen> barry: hesitate to limit things just because could confuse multiple clients
[14:13:50] <cnewman> Do we permit mailbox annotations on vmailboxes?
[14:13:53] <arnt> ray, just use flags, works fine.
[14:13:56] <tonyhansen> barry: balancing act
[14:14:03] <alexeymelnikov> dave: I think the draft on managing/listing contexts is missing. Once this is done one would be able compare vmailboxes versa contexts for the purpose of doing out-band notifications
[14:14:22] <cromwellian> chris, that's an open question. current vmailboxes are write-through and don't have their own state (or as little as possible)
[14:14:51] <Dave Cridland> Alexey: Yes, probably.
[14:14:58] <cnewman> If we permit mailbox annotations on vmailboxes, we could define a "type" annotation which can be searched.
[14:15:06] <tonyhansen> cyrus: can we search for virtual mailboxes using listext?
[14:15:20] <Dave Cridland> Alexey: Although I'm still perfectly happy to document my ACAP datasets I use for the purpose.
[14:15:49] <tonyhansen> cyrus: would allow various clients to discover if "my unseen messages" is already a known virtual mailbox and reuse it
[14:16:00] <tonyhansen> on to xencrypted
[14:17:18] --- xiaodong has left: Disconnected.
[14:17:43] <tonyhansen> glenn: is there a clear use case?
[14:18:19] <cromwellian> mostly says a) dont do it, b) if you must, tell your users to use end to end encryption c) if they don't, perhaps server can S/MIME messages from sender before they are FETCHed.
[14:18:23] <tonyhansen> stefan: text still needs beefing up
[14:18:34] <tonyhansen> eric: has a use case! (and a picture)
[14:19:22] <tonyhansen> eric: email on enterprise imap server; untrusted imap proxy; server will never fetch unencrypted object
[14:19:23] --- Jerry Shih has joined
[14:19:43] <fanf> why on earth would you use an untrusted imap proxy?
[14:19:46] <cromwellian> eric, there is an attach where using CATENATE, the proxy can attack by constructing a BURL and have SMTP mail the plainttext document
[14:19:53] <cromwellian> s/attach/attack/
[14:20:08] <cromwellian> its not just FETCh that is the problem
[14:20:22] <NFreed@jabber.org> I'm afraid this is one of those things you might be able to lay out in theory (with a lot of work) but will never fly in practice.
[14:20:33] <tonyhansen> eric channels stefan: may have no choice
[14:20:54] <NFreed@jabber.org> But I guess I have no objection to having a profile of S/MIME or PGP or whatever for this purpose.
[14:20:58] <tonyhansen> eric channels more
[14:21:33] --- xiaodong has joined
[14:21:37] <cromwellian> use case = operator charging $$$ :)
[14:21:53] <tonyhansen> glenn/stefan: will update use case in doc
[14:21:56] <eburger> (I'm not going to channel that >:)
[14:22:05] <cnewman> fanf: A mobile network operator can block outbound 143 except via their proxy. And that operator might misuse that proxy in various ways, for example being too eager to respond to illegal interception requests from government agencies.
[14:22:10] <eburger> I meant (6)
[14:22:22] <tonyhansen> on to tcp challenged environments
[14:22:34] <Dave Cridland> Chris: WOuldn't they then also forbid the use of xencrypted?
[14:22:37] <tonyhansen> stefan describes
[14:22:43] <eburger> Dave: probably.
[14:22:55] <cnewman> Dave: yes. Personally, I think the solution to the problem is to shop for a mobile operator that won't require a proxy.
[14:23:36] <eburger> Is it the mobile operator requiring a proxy, or a "less than educated" enterprise setting up their firewall in such a way the mobile operator has to use a proxy?
[14:24:13] <cromwellian> basically, we use IMAPURL as a kind of REST to fetch messages and sync mailboxes over delayed asynchronous networks like satellite modems
[14:24:29] <resnick> I can't express, even at the mic, how nauseated this whole TCP-challenged environment thing makes me.
[14:24:39] <resnick> (Don't channel that.)
[14:24:47] <tonyhansen> glenn/stefan further clarifies doc
[14:25:19] <cromwellian> ok, if you dont have TCPs, you send IMAPURLs to fetch messages to a proxy which turns them into TCP requests on your behalf
[14:25:52] <eburger> Resolution: Editors will fill out text
[14:26:22] <⎈> is draft-maes-lemonade-tcp-challenged-environments a wg doc at this point?
[14:26:24] <fanf> can we write a standard that says these operators are idiots, instead of standardizing ways to do IMAP-over-braindamage?
[14:26:39] <pguenther> fanf:
[14:26:41] <tonyhansen> on to 2192bis
[14:26:43] * pguenther fumbles
[14:26:43] <Dave Cridland> Fanf: That's what deployments says.
[14:26:46] <⎈> I ought to know, but I don't
[14:26:58] <tonyhansen> no update from interim
[14:27:07] <tonyhansen> still an outstanding issue
[14:27:13] <pguenther> fanf: that's a de-facto standard already, no need for IETF standards track
[14:27:29] <cromwellian> tcp-challenge-envuronments draft refers to deployments and says "this is the preferred way"
[14:27:55] <cromwellian> it basically says "dont do this, EVER, unless of course, you are on a set-top box or oil-rig in the north atlantic, then you might do this"
[14:28:31] <tonyhansen> phil jumps queue, then jumps back :-)
[14:28:48] <Dave Cridland> Do they have set-top boxes on oil rigs in the north atlantic?
[14:29:16] <cromwellian> maybe, if its DVB or DirecTV? :)
[14:29:20] <tonyhansen> alexey: will try again, but may require imapurl stuff to be folded in
[14:30:02] <cromwellian> there is a OCAP/GEM standard Java environment for these boxes which has a weird HTTP over MPEG mechanism for embedding data inside broadcast streams
[14:30:31] <cromwellian> there are also some asymmetric cable-tv boxes which have stream down, but only dialup and have big delays
[14:30:38] <tonyhansen> (urlauth)
[14:31:01] <fanf> (yeah i've deen the drafts for ip-over-mpeg-framing going past. omgwtfetc)
[14:31:46] <tonyhansen> glenn: would also need urlauth bis? not necessarily
[14:32:17] <tonyhansen> alexey: more work is needed, by next rev of draft
[14:32:21] --- alexeymelnikov has left
[14:32:22] <eburger> URLAUTH bis can wait for DS time
[14:33:10] <⎈> uri-review@ietf.org, for those playing at home
[14:33:20] <tonyhansen> alexey: other issue: need URI expert ted: uri-review alexey: needs review
[14:33:36] <tonyhansen> on to profile
[14:33:50] <tonyhansen> glenn summarizes
[14:35:57] <cromwellian> what does gray on the slide mean? (filter management), and does checkmark vs bullet means something different? slide 17
[14:36:37] <tonyhansen> alexey: summarizes changes
[14:38:21] <tonyhansen> back to slide 17
[14:38:44] <tonyhansen> (phase bis MUST implement)
[14:39:15] <tonyhansen> glenn gives key to colors, checks
[14:39:15] <cromwellian> partial urls are done too I think
[14:40:05] <tonyhansen> stefan: filter management will need more than managesieve
[14:40:49] --- alexeymelnikov has joined
[14:41:12] <tonyhansen> glenn will update slide 17
[14:41:41] <tonyhansen> randy: questions filters? more than sieve?
[14:41:59] <tonyhansen> stefan: notificaition and mobile view
[14:42:45] <tonyhansen> randy: ok, filters is then part of notifications and not separate filters are "control of notifications" then, to clarify things
[14:43:46] <tonyhansen> on to next steps
[14:44:23] <tonyhansen> track issues using http://roundup.sourceforge.net/
[14:44:40] <tonyhansen> need a "comment marshal"
[14:45:07] --- resnick has left
[14:46:18] <cromwellian> is someone going to run and host roundup installed?
[14:46:23] --- resnick has joined
[14:46:23] --- resnick has left
[14:46:23] --- resnick has joined
[14:46:40] <tonyhansen> eric demos roundup
[14:50:56] <Dave Cridland> I like NTK's review of roundup: http://roundup.sourceforge.net/press.html
[14:51:43] <tonyhansen> will actually use www.softarmor.com/roundup/ or on supplemental site
[14:52:22] --- cnewman has left
[14:54:05] --- 力颯 has left: Logged out
[14:54:31] <tonyhansen> will be up by WGLCs of new docs
[14:54:40] <tonyhansen> on to milestones
[14:57:22] --- resnick has left
[15:00:24] --- alexeymelnikov has left
[15:00:44] <tonyhansen> do we need an interim? if so, looking for interim host
[15:01:25] <eburger> Anyone *want* an interim?
[15:01:56] <Dave Cridland> Depends if it's in a nice place my new employer will expense me to go to...
[15:01:57] <tonyhansen> supplemental web page: http://flyingfox.cantata.com/i-d/lemonade/
[15:02:28] <tonyhansen> barry plugs use of jabber for interim meetings
[15:02:46] <tonyhansen> randy: time lag problem in jabber?
[15:03:17] <tonyhansen> barry: occasional overlapped comments, but not a problem in practice;
[15:03:39] <Dave Cridland> Randy: You mean latency between people? Yes, because of typing, but if everyone's jabbering I think it works much better.
[15:03:40] <tonyhansen> glenn: how long?
[15:03:43] --- cyrus_daboo has left
[15:03:58] <tonyhansen> barry: dkim used 1 hour sessions every couple of weeks
[15:04:30] <tonyhansen> alexey: plugs jabber better than phone conferences
[15:04:49] --- eburger has left
[15:04:53] --- Mike Parsel has left
[15:05:01] --- ⎈ has left: Logged out
[15:05:01] --- smaes has left
[15:05:29] <tonyhansen> alexey: questions frequency
[15:05:46] --- Jerry Shih has left
[15:05:51] <tonyhansen> barry: expands on dkim experience
[15:06:08] <tonyhansen> adjourned
[15:06:08] --- cromwellian has left
[15:06:13] --- xiaodong has left
[15:07:42] --- tonyhansen has left
[15:08:54] <Randall Gellens> Dave, yes, I meant latency between people's comments because of the time it takes people to type comments, and to catch up on old comments if they get distracted
[15:10:23] <lemonade> Thanks. We are done.
[15:10:35] --- lemonade has left
[15:10:47] --- Randall Gellens has left
[15:17:33] --- leiba has left
[15:21:23] --- frodek has left
[15:23:28] --- alexeymelnikov has joined
[15:24:34] --- alexeymelnikov has left
[16:03:09] --- kmurchison has joined
[16:31:56] --- NFreed@jabber.org has left: Logged out
[16:41:40] --- kmurchison has left
[16:46:37] --- Glenn Parsons has left
[18:05:35] --- pguenther has left