IETF
apparea
apparea@jabber.ietf.org
Monday, 25 July 2011< ^ >
stpeter has set the subject to: IETF Applications Area
Room Configuration

GMT+0
[03:46:19] hildjj joins the room
[04:13:55] hildjj leaves the room: Disconnected.
[09:36:02] Bjoern joins the room
[12:38:47] sandoche joins the room
[12:50:02] linuxwolf joins the room
[12:50:21] nx joins the room
[12:50:56] sandoche leaves the room
[12:52:08] Ted joins the room
[12:54:28] jlcJohn joins the room
[12:54:33] hildjj joins the room
[12:54:50] hildjj leaves the room
[12:54:54] hildjj joins the room
[12:56:32] hildjj leaves the room: Disconnected.
[12:57:26] sm.resistor joins the room
[12:57:40] linuxwolf leaves the room
[12:59:32] hildjj joins the room
[13:00:51] Yves Lafon joins the room
[13:01:04] msk joins the room
[13:01:06] yevst joins the room
[13:01:48] linuxwolf joins the room
[13:02:29] yone joins the room
[13:02:36] josephyee joins the room
[13:04:17] sandoche joins the room
[13:04:26] <hildjj> about: URI scheme
[13:04:31] <hildjj> name of caller?
[13:05:00] <msk> Lachlan Hunt, I imagine (see agenda)
[13:05:12] stpeter joins the room
[13:05:29] <hildjj> nod, got it: http://tools.ietf.org/html/draft-holsten-about-uri-scheme
[13:05:57] <stpeter> hildjj: are you channeling questions from the jabber room to the physical room?
[13:06:19] <hildjj> stpeter: i didn't sign up officially for either direction, but noticed neither was happening.
[13:06:47] <stpeter> I'm right at the mic so I'm happy to channel questions
[13:07:28] <msk> i think they forgot to ask
[13:07:48] <hildjj> if anyone here has a question they want channeled, prefix with mic:
[13:10:28] resnick joins the room
[13:11:33] Jim Galvin joins the room
[13:11:51] Atarashi Yoshifumi joins the room
[13:12:10] linyi joins the room
[13:12:27] <linyi> where can i find the uri scheme draft?
[13:12:41] <hildjj> http://tools.ietf.org/html/draft-holsten-about-uri-scheme-06
[13:12:44] <sm.resistor> http://tools.ietf.org/html/draft-holsten-about-uri-scheme
[13:12:53] <linyi> thanks
[13:13:24] <linyi> is this the request from w3c?
[13:13:50] <hildjj> fwiw, I agree with Ted. if we're going to do about: at all, it should be permanent and have a lightweight registry.
[13:13:56] bkihara.l joins the room
[13:14:31] <linyi> why it is not listed in APPArea portal?
[13:14:44] <sm.resistor> It is listed on the agenda
[13:15:18] <linyi> i also think a registry would be better.
[13:15:28] <hildjj> http://tools.ietf.org/html/draft-zyp-json-schema
[13:18:08] yevst leaves the room
[13:18:10] <linyi> does json schema also define how to describe a tree structure?
[13:18:14] <jlcJohn> (were there slide numbers, it would help to post them in jabber as we go...)
[13:18:38] <stpeter> no slide numbers in the desk
[13:18:40] <stpeter> deck
[13:18:40] <msk> "Sample: JSON Schema" now
[13:18:42] vincent-afnic joins the room
[13:18:43] <hildjj> linyi: you want that asked at the mic?
[13:19:01] <stpeter> linyi: are you in Quebec City?
[13:19:14] <linyi> yes
[13:19:41] <linyi> i just want to get some early feedback from this group
[13:20:01] <stpeter> ok :)
[13:20:25] sm.resistor is now known as sm
[13:20:25] sm is now known as sm.resistor
[13:20:38] sm.resistor leaves the room
[13:22:11] Behnam Esfahbod joins the room
[13:22:21] Behnam Esfahbod leaves the room
[13:22:45] sm.resistor joins the room
[13:22:54] behnam joins the room
[13:24:34] <resnick> If you're going to need code to parse schemata, why not just have code to parse XML schemata and use that?
[13:24:57] <hildjj> a) because the XML data model is different enough from JSON that it's a PITA.
[13:25:08] <hildjj> b) the code to process XML schema is **hard**
[13:25:31] sm.resistor is now known as sm
[13:25:31] sm is now known as sm.resistor
[13:26:00] sm.resistor leaves the room
[13:26:02] hildjj leaves the room: Disconnected.
[13:26:16] hildjj joins the room
[13:26:20] sm joins the room
[13:26:40] Yves Lafon leaves the room
[13:26:52] <stpeter> Linyi Tian at the mic
[13:27:07] <stpeter> Joe HIldebrand at the mic
[13:27:27] Jim Galvin leaves the room
[13:27:39] <linyi> i also think this work
[13:27:42] <linyi> is useful
[13:27:52] linuxwolf leaves the room
[13:27:59] Jim Galvin joins the room
[13:28:11] Ned Freed joins the room
[13:28:19] linuxwolf joins the room
[13:28:23] <stpeter> that was RIchard Barnes at the mic
[13:28:33] <hildjj> webidl is more for API, json schema is more for data.
[13:28:35] Yves Lafon joins the room
[13:29:38] <linyi> does it mean this is accepted as WG item?
[13:30:16] <hildjj> linyi: that will happen on the list.
[13:30:17] <Ted> After confirmation on the list, yes.
[13:30:39] <linyi> ok, barry's question means "in scope"
[13:30:53] <linyi> thanks, ted
[13:31:03] <hildjj> if someone wanted to stop it, they probably would have spoken up just now.
[13:31:07] <stpeter> yes, always after confirmation on the list :)
[13:31:35] lef_jp joins the room
[13:32:27] Atarashi Yoshifumi leaves the room
[13:33:14] Atarashi Yoshifumi joins the room
[13:39:54] <linyi> https://datatracker.ietf.org/meeting/81/agenda/apparea-drafts.pdf
[13:40:09] <linyi> this agend is empty, right?
[13:40:40] <josephyee> http://www.ietf.org/proceedings/81/agenda/appsawg.txt
[13:42:19] Klensin joins the room
[13:44:56] <linyi> if the issues come up over time, it may take long time to finish this draft. or this draft would not be complete from the beginning.
[13:45:57] <linyi> the suggestion looks like a ticket system.
[13:47:33] <linyi> does IANA ever have a registry to record best practice issues?
[13:48:19] <Klensin> Interestingly, this is not, by definition, about non-robust MSAs. If one looks at this from a robustness principle standpoint, MSAa are obligated to be conservative about what they send. The 5321 rule about not injecting junk into the public network is ultimately a restatement of "conservative in what the MSA sends" into a firm rule. This spec is about telling receivers what "liberal in what you receive" means and constraining that.
[13:48:43] <stpeter> Klensin: good point
[13:50:02] Randall Gellens joins the room
[13:50:05] <Ned Freed> We could try and errata.
[13:50:28] <linyi> i think barry's sentence is reasonable
[13:50:49] hta joins the room
[13:52:20] <Ned Freed> The case for an errata is that the statement in the draft is actually unclear and unsuitable for this level of standardization.
[13:53:10] <linyi> RFC should be better since this remove the restriction for some usages. it is not unclear wording issue. a new use case for a new feature
[13:54:36] <resnick> Yeah, but if I'm the erratum reviewer (which, BTW, I am), I can't see how I can reasonably mark it as other than "Hold for Document Update". http://www.ietf.org/iesg/statement/errata-processing.html
[13:54:50] <Klensin> Ned, while I think the case against using errata as a long-term solution to this (and similar issues) is pretty strong, if we have decided what we want to do, I think publishing an erratum that points in the direction of an I-D while the latter is going through the refinement, approval, and publication process might be a helpful, and quick, solution.
[13:55:30] <msk> and harmless
[13:55:51] <Klensin> I think that may be the equivalent of what Pete just said, only putting the thing into the errata file as an "unapproved, being held, but you should know about this"...
[13:56:05] <Ned Freed> Fair enough.
[13:57:59] Ted leaves the room
[13:58:51] <hildjj> everything is UTF8. next question.
[13:58:58] <resnick> heh
[13:59:01] <stpeter> hildjj: :)
[13:59:21] <linuxwolf> heh
[13:59:40] <linyi> :)
[13:59:51] <Yves Lafon> which normalization ?
[14:00:30] <hildjj> Yves Lafon: normalization not needed for this use case.
[14:00:47] <linuxwolf> we don't always need a canonical representation
[14:00:55] <linuxwolf> sometimes text is just text
[14:01:01] <linyi> if there is no default one, would there be problems?
[14:02:07] <msk> there's always a default, it's just not required to be us-ascii
[14:02:20] <stpeter> application/t-shirt ?
[14:02:20] <linyi> print the issues on the t-shirt is the good idea
[14:02:30] <linyi> if you goto ietf meeting you are making presentation all the week:)
[14:02:36] <stpeter> (said msk)
[14:03:37] mnot joins the room
[14:03:48] Andrew Sullivan joins the room
[14:03:55] <msk> hi guys :)
[14:03:56] eliot.lear joins the room
[14:04:03] simo.veikkolainen joins the room
[14:04:55] jlaurens joins the room
[14:05:22] sdiamond joins the room
[14:05:51] mnot is tempted to perform a denial of service to the microphone
[14:06:07] <msk> heh
[14:07:40] <Klensin> charset="x-i-dont-have-a-clue-and-you-probably don't either" ?? :-)
[14:07:48] <msk> no x-!
[14:08:09] Ted joins the room
[14:08:17] simo.veikkolainen leaves the room
[14:08:53] <linyi> mic: the document needs to impact the IANA consideration of previous RFC (e.g. X- should not be registered)
[14:09:04] <Ned Freed> Does this have any impact on x- media type names?
[14:09:18] <resnick> Probably.
[14:09:22] <msk> i think it would have to, especially if they're actually registered
[14:09:58] lef_jp leaves the room
[14:10:23] <msk> did we skip the top level domain names thing?
[14:10:47] <linyi> i also agree that the impact should be carefully investigated and documented
[14:10:53] hayes15260 joins the room
[14:10:57] Andrew Sullivan leaves the room
[14:12:33] <Ned Freed> RIght now x- and x. media type names cannot be registered. If we removed their special status we could register some of these
[14:12:42] <Ned Freed> that are actually in use.
[14:12:58] hayes15260 leaves the room
[14:12:59] <mnot> why have hoops?
[14:13:00] kepeng_li\40jabber.org joins the room
[14:13:05] <Ned Freed> (I'm not advocating for or against this; I'm just pointing out the issue.)
[14:13:05] <Klensin> Ned: +1
[14:13:12] <linyi> why not allow private ones to be registered?
[14:13:28] Jim Galvin leaves the room
[14:13:33] <msk> Ned: probably futile to try to get the "x-" removed from those?
[14:13:40] kepeng_li\40jabber.org leaves the room
[14:13:42] kepeng_li\40jabber.org joins the room
[14:13:44] <mnot> why does the label need to be in the parameter name?
[14:14:01] <eliot.lear> (i'm not in the room) linyi: how would one distinguish between ietf-sanctioned and other?
[14:14:04] <resnick> ISTM that X-Mailer is stable, the "X-" notwithstanding.
[14:14:13] <Ned Freed> It depends. Sometimes we've managed to replace usage of an x- type with a real one, other times not.
[14:14:20] madison41651 joins the room
[14:14:22] <mnot> remember it's not just media types
[14:14:29] <Ned Freed> (I've never actually seen an x. type name used anywhere.)
[14:14:42] <msk> pete: i'd like to try registering Mailer and get everyone to use it
[14:14:56] <linyi> to eliot: you may need a tag to distinguish them
[14:14:56] <Ned Freed> Sure, x- headers are another case.
[14:15:05] madison41651 leaves the room
[14:15:07] panqiuling\40jabber.org joins the room
[14:15:39] <Randall Gellens> A vendor prefix makes more sense than an "x" prefix, I think
[14:15:44] <linyi> Peter: would it be a draft?
[14:17:28] Atarashi Yoshifumi leaves the room
[14:18:16] <Ned Freed> The biggie here IMO are the changes to standards tree registration… Currently IESG approval is required, we're proposing changing that to expert review except for the determination of standards body status (that stays with the IESG).
[14:18:22] <Ned Freed> We need reviews!!!
[14:19:59] <Ned Freed> Right - additional changes are needed to fully implement the new standards tree process.
[14:21:08] <mnot> Ned: I will review soon
[14:21:12] <msk> ditto
[14:21:35] <Ned Freed> I have no objection to adding additional fields for sniffing and guessing information - someone just needs to explain what those fields
[14:21:36] <Ned Freed> are.
[14:22:09] <Ned Freed> However, I STRONGLY OBJECT to making any of this stuff a mandatory part of the registration. That's a recipe for people not registering stuff.
[14:22:29] <mnot> +1
[14:25:01] <stpeter> https://datatracker.ietf.org/doc/draft-liman-tld-names/
[14:25:16] <stpeter> see also https://datatracker.ietf.org/doc/draft-pettersen-subtld-structure/
[14:25:45] <stpeter> (ah, n/m, unrelated)
[14:27:01] <resnick> Ned/John - 4.12: I think the IESG is going to quickly move toward having IANA notify the IESG about SDOs wanting to register. That is, everyone will get to go to IANA, and IANA will deal with getting IESG to determine appropriateness and track the registration.
[14:27:35] <Klensin> wfm
[14:28:49] <Ted> Hmm, after a slide entitled "the gory detals" the line populates rapidly....
[14:29:58] <Ned Freed> Pete - this needs to be at least partly reflected in the registration doc.
[14:30:15] <resnick> ack
[14:30:44] <Ned Freed> And some of this probably impacts the registration form, but we normally don't talk about such specifics in the docs.
[14:33:15] <Klensin> "anything from 5890 is allowed" permits hypens and digits (from all scripts). Probably don't want to go there.
[14:35:38] <Ted> Could the chairs ask this slightly differently: "What in the application layer will break if we do this (or since we have done this)?"
[14:40:17] Jim Galvin joins the room
[14:40:43] behnam leaves the room
[14:41:33] <linyi> which authority is qualified to give the value of the identifier?
[14:42:29] <linyi> ok, it is out of scope according to this slide
[14:43:39] sdiamond leaves the room
[14:48:04] eliot.lear leaves the room
[14:48:22] Andrew Sullivan joins the room
[14:48:28] <Klensin> Ted, we actually a long history of funny behavior in that space, largely because of systems wanting to do name-completion of various sorts. and making the relevant heuristics as tight as possible. Some of that is in name to address translation APIs (gethostinfo and friends), not in what we normally consider applicaitons. When the new TLDs were introduced in 2002, some "didn't work" because applications "knew" that TLDS were 2 or 3 characters or .ARPA -- anything else was "obviously" bogus. For this IDN expansion into the root,
[14:49:51] fielding joins the room
[14:50:59] <Klensin> the idea right now is to make the minimum extension to the 1123 rule needed to make the current policies valid. Think of that as "minimum" in terms of permittd characters" and not "minimum text" and you get the current proposal. IMO, It is useful in that context (as Andrew implied) to remember that it is easy to expand the collection of permitted characters later should that be necessary but basically impossible to contract it. So small steps are appropriate.
[14:51:58] Andrew Sullivan leaves the room
[14:52:00] <Ted> My point wasn't really to assume that nothing would break but to say that the role of the APPSWG would be input to the policy folks on what would break (or be enabled) by a specific change. We seemed to be slipping into a mode where we were asking the group to specify what the policy should be.
[14:52:21] <Klensin> Ack.
[14:52:30] Andrew Sullivan joins the room
[14:54:04] jlaurens leaves the room
[14:54:05] Ted leaves the room
[14:55:42] hildjj leaves the room: Disconnected.
[14:55:46] hildjj joins the room
[14:56:21] <resnick> So, where in any RFC other than a note in the "DISCUSSION" section that *requires* that a top-level domain is entirely alphabetic? I can find none.
[14:56:26] <fielding> IANA does not currently have a URI for each media type. It could, but that would require instruction via an RFC.
[14:57:00] <resnick> (note in the "DISCUSSION" section of 1123)
[14:57:26] <Andrew Sullivan> There isn't one. The question is whether that section of DISCUSSION is actually normative.
[14:57:49] <Klensin> Pete, that "discussion" text in 1123 is actually an early manifestation of the IETF/IAB- IANA boundary. Happy to explain/review it (at lengh) at your convenience.
[14:58:10] <Andrew Sullivan> We have heard arguments that it is. I don't personally think it is, but as jck pointed out in one of the three moments I've been attached to this room, lots of people have interpreted traditional restrictions as rules
[14:58:21] <Andrew Sullivan> I still have problems with .info email addresses in some places.
[14:58:51] <Klensin> Andrew, it isn't normative on the IETF. It is normative on the part of the IANA function that actually makes decisions. If we want to open that can of worms, the comments need to go into the FNOI response(s) :-(
[14:59:20] <resnick> But that indicates to me that this is *not* a protocol question.
[14:59:24] <Andrew Sullivan> Or else the IANA function that makes decisions has to say, "That policy is no longer in effect."
[15:00:18] Ted joins the room
[15:00:20] <Andrew Sullivan> One reading of that note is that it is a statement of a clear policy. The IANA function could update that policy. OTOH, it has always been reluctant to update policy contained in RFCs
[15:02:35] <fielding> It's a friggin website ... no need to call it REST.
[15:03:05] <mnot> s/rest/http/g
[15:03:47] <msk> httpful?
[15:04:13] <stpeter> webful?
[15:04:19] <stpeter> webby
[15:05:49] <Klensin> Pete, it has never been a protocol question except insofar as it tells people who implement protocols what they can reasonably expect and what they can treat as nonsense... in that sense, no different from a MUST in 5322 vis-a-vis a delivery system.
[15:06:28] Jim Galvin leaves the room
[15:07:00] <fielding> It is information. We want to publish it on the Web. Most people just call that a website. JFDI.
[15:07:35] sandoche leaves the room
[15:08:04] <mnot> actually, I think this is a Cloud Restful Service Infrastructure.
[15:08:12] <mnot> probably need some more -ive's in there
[15:08:36] Jim Galvin joins the room
[15:08:48] <mnot> Bus! It needs a bus!
[15:10:07] <Andrew Sullivan> It's a Rain Cloud Restful Service Architecture Structure Component. How's that? (Expansions for RAIN solicited.)
[15:10:26] <msk> Registration Activity Information Network
[15:11:00] <Andrew Sullivan> Ooh, excellent
[15:12:15] <Andrew Sullivan> BTW, I re-checked my calendar, and 20:00 is indeed the time on Thursday
[15:12:19] <msk> WEIRDS is my fault though, so i should probably lay off with the acronyms
[15:12:28] <Ted> fielding: if it is limited to a single website and does not required structured referral, this gets a lot easier. Some of the registry models in use when IRIS was written did not allow that, because what were essentially business rules on who could query for what (e.g. requiring a registrant to query through their registrar). If it weren't for that, you could do this all with a wiki.
[15:12:37] g.e.montenegro joins the room
[15:13:05] <Andrew Sullivan> there is considerable desire to have permissions-based queries, however, depending on the client's status
[15:13:21] Randall Gellens leaves the room
[15:14:03] <hildjj> Andrew Sullivan: are there requirements for structure in the response as well? Some sort of semantics around dates, rather than regexing for them, for example?
[15:14:10] <Andrew Sullivan> yes.
[15:14:12] <Ted> Does the web site being queried know the client's status directly, or does it have to derive it from other actors?
[15:14:35] <Andrew Sullivan> although the requirements are so far pretty slim. But date handling is one that is already clearly stated
[15:14:41] <msk> definitely
[15:14:45] <msk> (re: date handling)
[15:14:54] <Andrew Sullivan> the current plan is that the site being queried knows the client's status directly
[15:14:56] <sm> Ah, anti-abuse ...
[15:14:59] <Ted> That is, does the registry have some way of knowing that the querier is the registrant, without querying the registrar?
[15:15:08] <msk> Ted: since it's HTTP, isn't client able to authenticate itself in some way?
[15:15:23] <Andrew Sullivan> what msk said
[15:15:24] <msk> at least in terms of class-of-service or such
[15:16:14] <Ted> msk: which http auth mechanism do you plan to use? "Login on form", I assume?
[15:17:09] kepeng_li\40jabber.org_ joins the room
[15:17:51] kepeng_li\40jabber.org leaves the room
[15:18:02] <fielding> hardie: there are no such requirements on WHOIS. I agree that client limiting is needed now. There is no need for anonymous access to WHOIS and there is no need for IETF agreement on the specific access mechanisms used. It is just a website.
[15:18:08] <mnot> you could wait for the http-auth work to complete.
[15:18:59] <msk> this isn't my strong suit, but i'll wing it: can't https do client-side authentication?
[15:19:00] <fielding> you could wait for the http-auth work to *start*
[15:19:07] <mnot> :)
[15:20:29] yoiwa joins the room
[15:20:59] <Ted> fielding: there were on IRIS, which is why I said start with its requirements doc and strike through. I suspect (but could easily be wrong) that folks moving from whois to anything else will want things to cease being a hack. If it is really "move my hack to this new substrate", then I agree you can do this on a web site now. As I said, without the business rules requirements, you can do this with a wiki.
[15:21:46] <Andrew Sullivan> we _do_ do this with websites now. Much of whois access is now actually via web sites today
[15:21:51] <Ted> In the past people have wanted at least a consistent hack, so that the folks who have to deal with multiple upstream providers don't have to have their systems special case every one.
[15:22:00] <Ted> Not that whois gives you this now, mind you.
[15:22:43] <Andrew Sullivan> right
[15:24:14] g.e.montenegro leaves the room
[15:25:01] <Klensin> And, Andrew, the websites are inconsistent and often more hacks. One of the nice features of IRIS was turning the requirements here into a protocol, rather than another (less cheap) hack. It would be really nice if that were considered a not-very-weird requirement.
[15:26:22] hta leaves the room
[15:26:45] <Andrew Sullivan> Note that Andy is one of the people who wrote one of these prototype protocols. He's at least as familiar with the iris problem statement as anyone else. I don't think anyone underestimates the problems here. Personally, I'm sceptical that whois can be reproduced in such a way that it doesn't end up a hack anyway, because it seems to be one protocol overloaded for several completely different problems.
[15:27:05] <Andrew Sullivan> which I think, John, was part of what you were saying
[15:27:52] Jim Galvin leaves the room
[15:28:33] <fielding> hardie: I have no doubt that there were many unnecessary and obscure requirements placed on IRIS -- that is true of any protocol designed by committee. The value of treating it as "just a website" is that people can start with something simple.
[15:28:49] <fielding> This whole "touching humans" thing is weirding me out.
[15:30:00] <Klensin> Yes, that is exactly what I was saying. My hypothesis is that one can generate clear requirements and a corresponding protocol for any one application of the system ("application" = "address registry", "top level name registry", "other name registry", "root zone registry", "local system user directory info",...). If you try to take the union (or product) of those applications, you are likely to end up with enough contradictory requirements to require enough compromises to result in useless (or more hacks).
[15:30:19] vincent-afnic leaves the room
[15:30:54] resnick leaves the room
[15:30:54] Yves Lafon leaves the room
[15:30:54] Ted leaves the room
[15:30:58] yone leaves the room
[15:31:03] bkihara.l leaves the room
[15:31:10] josephyee leaves the room
[15:31:13] kepeng_li\40jabber.org_ leaves the room
[15:31:19] mnot leaves the room
[15:31:22] hildjj leaves the room: Disconnected.
[15:31:24] linuxwolf leaves the room
[15:31:27] fielding leaves the room
[15:31:40] nx leaves the room
[15:31:52] Andrew Sullivan leaves the room
[15:32:33] panqiuling\40jabber.org leaves the room
[15:33:07] Klensin leaves the room
[15:33:54] Jim Galvin joins the room
[15:34:18] sm leaves the room
[15:35:42] stpeter leaves the room: Disconnected: connection closed
[15:37:41] yoiwa leaves the room
[15:38:18] linyi leaves the room
[15:38:25] jlcJohn leaves the room
[15:39:50] Jim Galvin leaves the room
[15:54:23] Ned Freed leaves the room
[16:00:23] msk leaves the room
[16:04:00] Bjoern leaves the room
[16:48:42] resnick joins the room
[16:53:12] hta joins the room
[16:53:19] bkihara.l joins the room
[16:54:29] Ted joins the room
[16:54:50] Ted leaves the room
[16:56:48] bkihara.l leaves the room
[17:02:25] hta leaves the room
[17:02:28] hta joins the room
[17:03:31] hildjj joins the room
[17:06:38] stpeter joins the room
[17:07:21] linuxwolf joins the room
[17:09:12] hildjj leaves the room
[17:23:25] Yves Lafon joins the room
[17:23:44] mnot joins the room
[17:25:54] mnot leaves the room
[17:32:29] hta leaves the room
[17:52:50] msk joins the room
[18:01:24] hta joins the room
[18:05:17] Yves Lafon leaves the room
[18:24:30] Andrew Sullivan joins the room
[18:29:54] Andrew Sullivan leaves the room
[18:29:56] Andrew Sullivan joins the room
[18:30:24] Andrew Sullivan leaves the room
[18:31:10] linuxwolf leaves the room
[18:33:22] hta leaves the room
[18:33:24] msk leaves the room
[19:05:50] resnick leaves the room
[19:12:46] resnick joins the room
[19:14:05] Andrew Sullivan joins the room
[19:25:50] linuxwolf joins the room
[19:28:24] Andrew Sullivan leaves the room
[19:28:26] Andrew Sullivan joins the room
[19:34:55] Andrew Sullivan leaves the room
[20:18:31] resnick leaves the room
[20:45:53] msk joins the room
[20:59:52] resnick joins the room
[23:19:03] stpeter leaves the room: Disconnected: connection closed
[23:23:15] stpeter joins the room
[23:24:42] msk leaves the room
[23:36:16] stpeter leaves the room: Disconnected: connection closed
[23:36:16] linuxwolf leaves the room
[23:36:39] stpeter joins the room
[23:37:55] resnick leaves the room
[23:41:24] stpeter leaves the room: Disconnected: Replaced by new connection
[23:41:26] stpeter joins the room
[23:43:56] stpeter leaves the room: Disconnected: connection closed
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!