[04:43:00] --- alexeymelnikov has joined
[08:37:20] --- mrose has joined
[08:37:26] --- hardie has joined
[08:37:58] <mrose> hola.
[08:38:16] <mrose> meeting starts in 19 minutes
[08:39:45] <hardie> Que tal, Marshall?
[08:40:25] <mrose> eh?
[08:41:00] <hardie> Just saying hi.
[08:41:36] <mrose> ahhh...
[08:50:17] --- hardie has left
[08:51:39] --- Milele has joined
[08:51:43] --- Milele has left
[08:51:50] --- Lisa D has joined
[08:52:11] <Lisa D> Hola los amigos
[08:52:16] --- hildjj has joined
[08:52:30] --- hartmans has joined
[08:54:44] <hildjj> "¿qué tál?" is closer, and flashes the mad unicode foo.
[08:55:18] --- rjs3 has joined
[08:56:11] <hartmans> So, Joe, you know how I just told you I didn't have any issues?
[08:56:21] <hildjj> yes....
[08:56:29] <hartmans> Where is the text describing what cert checking is done for TLS?
[08:56:53] --- warlord has joined
[08:57:24] --- faceprint has joined
[08:57:38] --- eblanton has joined
[08:58:12] <hildjj> core, 5.1, point 7:
[08:58:19] --- faceprint has left
[08:58:23] <mrose> pete is in the room
[08:58:28] --- jhutz has joined
[08:58:41] --- nwalp has joined
[08:58:41] <hildjj> The initiating entity MUST validate the certificate presented by the receiving entity; there are two cases: Case 1 -- The initiating entity has been configured with a set of trusted root certificates: Normal certificate validation processing is appropriate, and SHOULD follow the rules defined for HTTP over TLS[12]. The trusted roots may be either a well-known public set or a manually configured Root CA (e.g., an organization's own Certificate Authority or a self-signed Root CA for the service as defined under High Security). This case is RECOMMENDED. Case 2 -- The initiating entity has been configured with the receiving entity's self-signed service certificate: Simple comparison of public keys is appropriate. This case is NOT RECOMMENDED (see High Security for details). If the above methods fail, the certificate SHOULD be presented to a human (e.g., an end user or server administrator) for approval; if presented, the receiver MUST deliver the entire certificate chain to the human, who SHOULD be given the option to store the Root CA certificate (not the service or End Entity certificate) and to not be queried again regarding acceptance of the certificate for some reasonable period of time.
[08:59:26] --- Lisa D has left: Replaced by new connection
[08:59:27] --- Lisa D has joined
[08:59:27] --- Lisa D has left
[08:59:30] <hartmans> Ah I see it.
[08:59:35] --- Lisa D has joined
[08:59:44] <Lisa D> Everybody ready??
[08:59:47] <eblanton> (while I'm on the big screen...) hi mom!
[09:00:12] <hildjj> hartmans: is that good enough?
[09:00:30] <mrose> meeting starts
[09:00:41] <hartmans> Kurt, who is sitting behind me believes that you should clarify that you check the name the user typed not something you got from DNS.
[09:01:03] <hartmans> I'm not sure that's worth cycling the draft, but if the draft ends up changing for other reasons it may be worth including a comment for that case.
[09:01:16] <mrose> agenda bashing: status of core/im documents, status of e2e/cpim docs, call for implementation reports, relate work, wg next steps
[09:01:23] --- anewton has joined
[09:01:46] <hildjj> hartmans: HTTP over TLS doesn't specify that?
[09:01:55] <mrose> hartmans: probably worth an edit during the 48 hour perio
[09:01:58] --- shep has joined
[09:01:59] <hartmans> http over tls does specify that.
[09:02:03] <mrose> pete: agenda approved
[09:02:17] <hartmans> Thus I don't think it is worth clarifying especially if you don't need to recycle the document
[09:02:25] <mrose> 1. status of core/im documents
[09:02:27] <hildjj> nod. cool.
[09:02:36] --- shep has left: Disconnected
[09:02:37] <mrose> hartmans: i'm sure the rfc editor will find a typo or two...
[09:02:46] <mrose> 1. stpeter presenting
[09:03:03] --- shep has joined
[09:03:49] --- perry has joined
[09:04:10] --- ralphm has joined
[09:04:51] <hildjj> just so i understand, you're saying that if the user typed in "foo.com" that got looked up as a dns srv which returned "im.foo.com", the cert should be checked as "foo.com"?
[09:05:17] <hildjj> http://www.jabber.org/ietf/58/psa
[09:05:24] <warlord> hildjj: correct
[09:05:26] <mrose> [st] here are the changes since the iesg last call
[09:05:27] --- ermine has joined
[09:05:38] <mrose> [st] core status
[09:05:59] <ermine> cool
[09:06:02] <hartmans> Correct.
[09:06:03] <ermine> hello all
[09:06:10] <mrose> [st] clarification of authorization ID, allowed sasl security layer after tls negotiation, other small cleanups
[09:06:18] --- resnick has joined
[09:06:24] <mrose> [st] clarification of authzid changs for /resoures
[09:07:00] <mrose> [st] xml:lang on <stream/>
[09:07:12] <mrose> [st] specified abnf for addrs format
[09:07:21] <mrose> [st] added bas6 security considerations
[09:07:25] <mrose> [st] plus the usual edits
[09:07:28] <hildjj> (lisa's AIM pops up a notification that perry has logged in)
[09:07:32] <hildjj> (giggles)
[09:08:04] <mrose> ermine - hello from minnapolis
[09:08:41] * ralphm waves (a bit late) from the netherlands
[09:08:44] --- Lisa D has left: Disconnected
[09:08:47] <warlord> Isn't IM wonderful?
[09:09:07] --- jishac has joined
[09:09:22] <ermine> mrose: sorry i'm little busy
[09:10:22] <perry> I don't think this IM stuff will ever take off. Who would ever use it?
[09:10:26] <mrose> pete: has everyones' questions been addressed?
[09:10:35] <hartmans> What is the point of rule 1 regarding DNS in section 6? I don't think it is problematic but I don't understand it.
[09:11:23] <mrose> altman: saag had a discussion regarding sasl/tls .. tls should be ignored in that case .. will send some updated text
[09:11:42] <rjs3> ==hartmans
[09:11:44] <mrose> hildjj: is the existing text ok?
[09:12:12] <mrose> altman: we got a definitive answer yesterday
[09:12:20] <mrose> mahy: is there a reference to e2e?
[09:12:26] <mrose> stpeter: it's in the im document
[09:13:09] <mrose> pete: with regard to the references, post vienna, we moved any im from core to the im doc. core is independent of im, presence
[09:13:31] <mrose> zellinga: there were some nits i raised, not sure if all got addressed, i'll review it again
[09:13:40] <mrose> pete: what are we talking about?
[09:13:48] <mrose> zellinga: misplaced citations
[09:13:51] <hartmans> hildej - I suspect you won't get a strong consensus from the security community that you SHOULD double encrypt, although Jeff Altman believes you should.
[09:13:57] --- ohm has joined
[09:14:08] <hartmans> If this working group agrees with Jeff, I don't think you will get objections from the security community either.
[09:14:28] <mrose> pete: if there are specifics that can't be done in 48-hour period, i want to know immediately
[09:14:46] <mrose> stpeter: what about mutual auth with tls
[09:15:00] <hildjj> hartmans: this is an issue that i have no strong feelings about. as long as the security mafia can agree, we'll put in their text.
[09:15:08] --- lschiere2 has joined
[09:15:12] <hildjj> is altman a cannonical source?
[09:15:26] <mrose> many: for mutual auth in s2s, if you exchange certs, you can skip the round-trips associated with sasl
[09:15:49] <mrose> hildjj: do sasl external, the round-trips won't kill you the connections last for ays
[09:16:45] <mrose> mahy: the 3 extra round-trips aren't an issue for long-lived connections, but if they're short-lived...
[09:17:01] <mrose> hartmans: in the apps area, we do mutual tls with external... that's the bcp
[09:17:14] <mrose> stpeter: that's what we based it on
[09:17:54] <mrose> cullens: what does the doc say?
[09:19:02] <mrose> hildjj: you MAY do mutual auth, i so, the server MAY offer EXTERNAL; however, you may not skip SASL
[09:19:12] --- hardie has joined
[09:19:38] <mrose> pete: how many people feel qualified to decide [[some]] how many want a change [[none]] ... judgment: no change
[09:19:50] <mrose> [stpeter] onto im doc
[09:20:07] <mrose> [stpeter] added missing server handling rules for <user@host/resource> cases
[09:20:16] <mrose> [stpeter] clarified privacy rules syntax
[09:20:28] --- hartmans has left
[09:20:28] <mrose> [stpeter] clairified several points regarding session establishment
[09:20:44] --- hartmans has joined
[09:21:38] <mrose> [stpeter] all this is about clarifying the existing practices, etc.
[09:22:37] <mrose> [pete] have any outstanding last call questions not been addressed? [[no hands]] ... judgment: none
[09:22:43] <hartmans> Responding to Joe's question about whether Altman is a canonical source? He was the one who asked the questions in SAAG. I'd expect if you ask him what the explicit questions/answers he got were, he would accurately tell you. One question was whether people thought there was a *security* problem with double encryption. People did not think there was such a problem. Whether you recommend double encryption, require it, or only allow it is all about performance/security tradeoffs and it is basically going to be something you have to decide.
[09:22:52] <mrose> [stpeter] e2e/cpim docs updated in august
[09:23:12] <mrose> [stpeter] e2e one minor fix
[09:23:34] <hildjj> hartmans: we'll make sure to get appropriate text from altman.
[09:23:36] <mrose> [stpeter] cpim: addresses issues of PIDF mappings with multiple tuples
[09:23:59] <hartmans> I don't remember Jeff's second question. Jeff is arguing for a position that is fairly close to the security end of the security/performance space. It's a valid position to argue; I would certainly be happy if you adopted that position, but I'm not sure I'd actively advocate a position that strong.
[09:24:01] <mrose> [stpeter] cpim: addresses issues of JID mappings to instant inboxes
[09:24:12] <mrose> hartmans: thanks!
[09:24:32] <mrose> [lisa] we're going to do a wglc on these docs after this meeting
[09:25:25] <mrose> [hardie] the impp dns srv doc establishes a registry, one of the docs, e.g., im, should make a registration application
[09:26:00] <mrose> [stpeter] that change shall be made
[09:26:08] <mrose> [pete] looks like we're coming in for a landing!
[09:26:38] <mrose> [lisa] as of now, we have no plans for another meeting [[applause]] the mailing lists will move on to discuss interesting things
[09:27:26] <mrose> [lisa] implementations/interop stuff: we can get together on the list to discuss things as needed.
[09:28:05] <mrose> [lisa] even though there's a lot of activity independent of the mailing lists
[09:28:28] <mrose> [hardie] are there any reports of any implementations of the e2e/cpim with simple
[09:28:57] <mrose> [hardie] i'd prefer that the wg not shutdown until we see some experience
[09:29:57] <mrose> [lisa] there is some cpim experience, but we haven't seen any of the e2e stuff
[09:30:22] <mrose> [perry] is this "charter work"?
[09:30:35] <mrose> [hardie] i think that the common handle work is part of the charter
[09:30:44] <perry> chartered work. :)
[09:30:56] <perry> the "ed" was important.
[09:31:32] <mrose> [cullens] there's a siplet interoperability event with an open source s/mime client we've tested with... that was useful for checking the document... i can help test
[09:31:51] <mrose> perry: right you are
[09:31:51] --- xmpp has joined
[09:32:03] <mrose> [lisa] please post a pointer, thanks!
[09:32:19] <mrose> [cullen] i was referring to the sip document
[09:33:00] <mrose> [stpeter] that would be helpful to work with... also, can someone provide me with an implementation report
[09:33:15] <mrose> [mrose] there are 46 entries on the blue sheet, anyone else?
[09:33:54] --- pgm has joined
[09:34:39] <mrose> [ethan] th gaim developer, it was easy to add xmpp to the implementation... and to keep
[09:34:58] <mrose> [zelligna] go to the iesg page and you'll find examples
[09:36:06] <mrose> [lisa] cpim/e2e are parts of the charter, we need to think about common handles and extended presence are in the existing charter
[09:36:31] <mrose> [lisa] then there's new stuff like application-leel notifications, extended conferencing
[09:36:42] <mrose> [day] can you clarify common handles, extended presence?
[09:37:04] <mrose> [lisa] things that would be shared across diverse im systems... may already have been done by impp wg
[09:37:41] <mrose> [hildjj] need to double-check all the cases around the edges... we already have stringprep'd the jids, etc.
[09:37:55] <mrose> [lisa] are we taling about impp urls?
[09:38:08] <mrose> [hildjj] yes, but specifically the stuff in simple
[09:38:33] <mrose> [day] if common handles don't work now, then that's current work
[09:38:54] <mrose> [hildjj] the different communities are still analyzing whether there are gaps in the diagram
[09:39:06] <mrose> [lisa] joe volunteers
[09:39:28] <mrose> [stpeter] wrt extended presence, how do we do things like RPIDs
[09:40:42] <mrose> [stpeter] looks like we can embed PIDF/RPIDs into <presence/> ... the jabber community, liberty alliance, etc., are looking at things similar to this, and may be able to provide some additional input for RPIDs
[09:41:38] <mrose> []: the simple wg renamed RPIDS to RPID, and it's winding down
[09:41:50] <mrose> [lisa] is this sip/simple specific?
[09:41:53] <mrose> []: nope
[09:42:18] <mrose> [lisa] any other questions? [none] no.
[09:42:23] <mrose> [] = sparks...
[09:42:45] <mrose> [lista] what about application-level presence? [[hands]]
[09:43:43] <mrose> [lisa] examples of notifiation things going on: [[lots of boxes with words like calendaring, lemonade wg, etc...]
[09:44:19] <mrose> [lisa] a notification aggregator combines events from ...
[09:44:19] * ralphm thinks of an jabber enabled desktop
[09:44:25] <ralphm> right
[09:45:09] <mrose> [lisa] example of a voicemail notification event: <message to='... from='''> <body>...</body> <xnap> ... pointer ... </xnap> </message>
[09:45:26] <mrose> [lisa] this is just a back-of-envelope example
[09:45:33] <ralphm> longhorn is going in this direction, but not far enough from what I can see so far
[09:45:41] <ralphm> I think they use sip/simple for this
[09:45:53] <hildjj> xnap is pronounced "shnap" with an 'a' like in "cat".
[09:46:06] <mrose> [lisa] i'm going to put together an individual I-D for lemonade, they're the furthest along in the ietf
[09:46:33] <mrose> [stpeter] now, about extended conferencing
[09:46:57] <mrose> [stpeter] draft reserves a "groupchat" type, but doesn't define it.
[09:47:11] <hildjj> http://www.jabber.org/jeps/jep-0045.html
[09:47:17] <hildjj> is the doc he's talkkng about.
[09:47:21] <mrose> [stpeter] in the jabber community, there's an older protocol and a newer one, muc ... jep45
[09:47:36] <mrose> [stpeter] is this a potential future item for the xmpp wg?
[09:47:54] <hildjj> btw, http://www.jabber.org/jeps/jep-0060.html is the pub/sub work that's been done in the JSF.
[09:48:10] <mrose> [pete] how does this relate to xcon, if at all
[09:49:25] <mrose> [stpeter] i've chatted with them, the models have some similarity, but i need to spend more time analyzing xcon. it may be useful for me to write-up a muc summary for the xcon work. but i'm not sure what the overlap is
[09:49:51] --- anewton has left
[09:49:52] <mrose> [cullens] xcon is still collecting data on text conferencing, so that would be useful
[09:50:44] <mrose> [cullens] it would be good to get the use cases and scenarios to xcon
[09:51:05] <mrose> hartmans: one of my great disappointments with the impp wg is that they put groupchat out of scope.
[09:51:14] <mrose> that should have been [hartmans]
[09:51:33] <mrose> [hartmans] i'd really like to see this in the ietf, particularly in the context of the xmpp, and i'd be happy to work on it
[09:52:08] <mrose> [lisa] what about xcon?
[09:52:31] <mrose> [hartmans] ... i really do not want to spend the same process we did with impp. i want to see this done right for xmpp
[09:53:37] <mrose> [roach] i want to re-iterate cullens point about getting muc scenarios to the xcon wg
[09:54:43] <mrose> [atkins] sam, i agree with you that im is important, groupchat was originally decided out of scope many years ago because it thought to be harder than the more basic stuff
[09:55:11] <ralphm> Do you want to rethink (not reimplement) groupchat from scratch and then look at muc or ...?
[09:55:22] <mrose> [atkins] so, let's not blame the impp wg
[09:55:45] <mrose> i think that sam raises a valid point about the xmpp-centric perspective
[09:55:55] <mrose> [day] if we could all get along, we could all get along
[09:56:19] <pgm> heh
[09:56:19] <hartmans> My point is roughly that if we can get a solution significantly faster and easier in an XMPP-centric way, we perhaps should.
[09:56:41] <mrose> sam, i agree
[09:56:53] <jhutz> xcon doesn't look to me like they're t
[09:56:57] <jhutz> oops
[09:56:58] <pgm> hartmans: you should checkout JEP-45.. it seemed pretty complete from an XMPP standpoint.
[09:57:14] <warlord> My main point is that not thinking of group messaging can cause scaling problems when you have large, dispersed, but co-resident groups. E.g. chats among many many users at a number of different sites where there a significant number of communicants at each site.
[09:57:15] <hartmans> Note that this is a similar argument to e2e and I'm taking a very different position than I did in that case.
[09:57:16] <mrose> [day] please find a way to coordinate with the sip universe
[09:57:37] <mrose> derek, i agree with the scaling concern
[09:57:43] <jhutz> It looks to me like what xcon is trying to address is management of multimedia "conferences" (audio, video, etc), which is significantly different from group chat
[09:58:04] <ralphm> is it?
[09:58:13] <hartmans> I know I need to read jep-45
[09:58:16] <ralphm> there are a lot of the same concepts
[09:58:24] <warlord> mrose: ok, I just wanted to make sure that came across in the minutes.
[09:59:08] <mrose> [lisa] how may people want to work on groupchat syntax for xmpp, or semantics for multiple protocols, or ...
[09:59:25] <warlord> ralphm: I'm not convinced it is SIGNIFICANTLY different.. On the other hand, neither are IMs and Presence Notifications..
[09:59:42] <jhutz> mrose getting up to talk...
[10:00:01] <jhutz> mrose: can you tell me what the inter-arrival time of the word 'SIP' was in the xcon WG?
[10:00:08] <ralphm> warlord: heh
[10:00:13] <mrose> [roach] xcon isn't bound to sip
[10:00:21] <mrose> [mrose] sarcastic observation
[10:00:38] <warlord> ralphm: I'm absolutely serious -- come find me if you want me to explain in more detail.
[10:00:39] <mrose> [hartmans] is there a security model?
[10:01:02] <mrose> [roach] there must be, but we haven't done it yet
[10:01:14] <pgm> It seemed clear in the WG announcement that xcon is using the SIP notification system. Doesn't that bind it to SIP?
[10:02:05] <hartmans> I certainly labeled xcon as SIP-spawn when I read the new-work announcement;)
[10:02:17] <mrose> []: it would be a mistake not to do an xmpp-based groupchat
[10:02:26] <pgm> hartmans: as did I.
[10:02:33] <eblanton> [] == eblanton, sorry
[10:02:39] <mrose> [hardie] you can recharter this working group or maybe do a new one,
[10:02:45] <mrose> eblanton, sorry! typing to fast
[10:03:31] <mrose> [hardie] marshall thinks the extensibility model is using xmpp as an application-layer substrate, if that's the model, you need to decide whether groupchat should sit on top of the xmpp substrate, or not?
[10:03:57] <mrose> [hardie] it would be useful to take this to the list to see what kind of work would this entail
[10:04:18] <mrose> [hardie] this will help decide whether its a re-charter or a new wg kind of thing
[10:05:00] <hartmans> Will we have to change xmpp for the scalability issues? I.E. can I deliver one copy of a message to a site? Do I even care?
[10:05:11] <mrose> [hildjj] the jabber community spends a lot of time trying to reuse our own protocols, e.g., pubsub as a generic model for different things. groupchat is another example of that philosophy
[10:05:21] <warlord> hartmans: yes, you care
[10:05:37] <pgm> hardie: there is nothing in the current docs that would prevent that (AFAIK), and I think we do care.
[10:06:10] <mrose> [mahy] how many people would be willing to contribute text for media-specific requirements for text conferencing
[10:07:06] <mrose> note: i don't have a power outlet here... may need to ask for another scribe soon
[10:07:35] --- thatoneguy has joined
[10:07:44] <mrose> [mahy] what is the flavor for folks doing text conferencing
[10:08:40] <jhutz> (Heh. Someone is helping mrose get powr. it is amazing the efforts to which people will go to avoid becoming scribe)
[10:08:55] --- Lisa D has joined
[10:08:57] <pgm> jhutz: LOL
[10:09:08] <mrose> [stpeter] there' a lot of stuff in the jabber community... we really wanted to take the very core stuff to the ietf. there's a lot of wealth out there going on
[10:09:09] <jhutz> (actually, I guess "someone" was Pete, so s/avoid becoming/avoid losing/)
[10:09:56] <mrose> [stpeter] they started doing conferencing back in '99... the muc spec was written based on experience but also backwards-compatibility
[10:10:11] --- Lisa D has left: Replaced by new connection
[10:10:11] --- Lisa D has joined
[10:10:12] --- Lisa D has left
[10:10:26] --- Lisa D has joined
[10:10:29] <mrose> [stpeter] our model is that there's a server that does the base core stuff, all the bells and whistles in components that sit on top of that
[10:11:33] <mrose> [stpeter] personally, the xmpp defined the stuff that impp required, now there's all this other stuff to do... the question is how to structure a way of doing extensions
[10:12:13] <mrose> [hildjj] perhaps we might see an ietf/w3c relationship between ietf/jsf... just a possibility
[10:13:18] <mrose> [hartmans] the question is whether the ietf has things to bring to these proposals? there may be scaling issues in the groupchat and other areas. the ietf is a good forum for cross-area review. there's a lot of value there
[10:13:50] * ralphm nods
[10:14:05] <mrose> [hardie] ditto sam, there are some building blocks where the cross-area review would be helpful
[10:14:05] <jhutz> (are RFC numbers shiny?)
[10:14:10] <pgm> One of the big areas that the JSF is lacking in is security reviews. The IETF can help a lot there.
[10:14:19] --- leg has joined
[10:14:29] <mrose> pgm: absolutely
[10:14:32] <rjs3> only if you polish them
[10:14:43] <pgm> rjs3: what do you mean?
[10:14:53] <rjs3> (to jhutz)
[10:14:55] <mrose> [hardie] similarly, there's a lot of stuff outside of the ietf's interests, e.g., avatar design.
[10:14:56] <pgm> oh :)
[10:14:56] <ralphm> rfc numbers are shiny if you polish
[10:15:34] <mrose> [mahy] the conferencing stuff is cross-domain
[10:15:56] <Lisa D> 'net conf' is network configuration, not conferencing, no?
[10:16:02] <mrose> [mahy] netconf bof'd in yokohama when you did.
[10:16:04] <mrose> lisa: yes
[10:16:07] --- hardie has left: Disconnected
[10:16:15] --- hardie has joined
[10:16:23] <warlord> Mmm.. history...
[10:17:35] <mrose> [day] 2778 was about agreeing on the concepts that everyone could agree on, 2779 was about the minimal interoperability requirements, so i'm uncomfortable with viewing 2779 as "done" if we still lack basic interoperability
[10:18:31] <mrose> [metzger] it seems to me that the right thing to do is to discuss. on the mailin list, what kinds of followon should be in scope
[10:18:37] <hartmans> While I agree with perry are there any shows of hands we could do here?
[10:18:38] <mrose> [pete] i agree
[10:19:01] <hildjj> show of hands on *that*.
[10:19:27] <pgm> what was perry's statement?
[10:19:48] --- alexeymelnikov has left: Disconnected
[10:20:19] <mrose> [lisa] where to discuss stuff: groupchat -- let's discuss that on the list, as to where to discuss
[10:20:26] <hartmans> Conclusion: no;)
[10:20:40] <mrose> [lisa] common handles: joe will do the analysis
[10:21:03] <hildjj> pgm: the question was whether we wanted to do groupchat in xcon. we didn't take a hum since it was clear that there wasn't consensus.
[10:21:04] <mrose> [lisa] pubsub: will discuss in other wgs
[10:21:21] <pgm> hildjj: *nod*
[10:21:34] <mrose> [lisa] xtended presence: needs analysis
[10:21:53] <mrose> [metzger] thank you to the chairs
[10:21:59] --- hardie has left
[10:22:05] <mrose> [lisa] thank you, it's been a pleasure
[10:22:14] <mrose> [pete] adjourn.
[10:22:15] --- ohm has left: Lost connection
[10:22:35] --- resnick has left: Disconnected
[10:22:39] --- eblanton has left: Disconnected
[10:22:46] --- lschiere2 has left
[10:23:03] --- thatoneguy has left: Disconnected
[10:23:23] --- alexeymelnikov has joined
[10:23:30] --- jishac has left
[10:23:59] --- pgm has left
[10:24:29] --- hildjj has left: Disconnected
[10:24:31] --- warlord has left
[10:24:41] --- rjs3 has left: Disconnected
[10:25:00] --- perry has left: Logged out
[10:26:24] --- ralphm has left
[10:27:45] --- hartmans has left
[10:31:25] --- jhutz has left
[10:34:53] --- Lisa D has left
[10:43:17] --- shep has left
[10:46:06] --- alexeymelnikov has left
[10:59:41] --- leg has left: Disconnected
[11:11:18] --- mrose has left
[11:19:25] --- ermine has left
[11:19:47] --- nwalp has left
[14:30:22] --- mrose has joined
[14:31:56] --- mrose has left
[16:50:24] --- xmpp has left