[14:00:48] --- julian.reschke has left
[14:36:03] --- adaviel has joined
[14:37:22] --- adaviel has left
[16:37:57] --- andrew.daviel has joined
[16:38:59] --- andrew.daviel has left
[16:45:42] --- julian.reschke has joined
[17:33:19] --- julian.reschke has left
[17:34:06] --- julian.reschke has joined
[17:45:44] --- andrew.daviel has joined
[17:46:32] --- andrew.daviel has left
[19:20:11] --- andrew.daviel has joined
[20:03:44] --- julian.reschke has left
[20:23:38] --- andrew.daviel has left
[20:30:08] --- arifumi has joined
[20:30:36] --- mnot has joined
[20:35:39] --- julian.reschke has joined
[20:44:00] --- Barry Leiba has joined
[20:45:12] --- guenther has joined
[20:45:13] --- aaronstone has joined
[20:45:39] --- stephen.morris has joined
[20:46:14] --- tlyu@jis.mit.edu has joined
[20:47:22] --- doug.otis@gmail.com has joined
[20:48:20] --- cyrus_daboo has joined
[20:48:47] --- randy has joined
[20:51:34] --- sayrer has joined
[20:51:52] <sayrer> scribe starting...
[20:51:58] <sayrer> mnot: Agenda Bashing
[20:52:19] <sayrer> Larry Masinter: HTTP how we got there and where we should go (Presentation)
[20:52:26] <sayrer> HTTP 1.1: how we got here
[20:52:31] <sayrer> - One click per document
[20:52:35] --- tonyhansen has joined
[20:52:41] <sayrer> - Oops: IMG tags for documents
[20:52:47] <sayrer> - scaling issues lead to HTTP/1.1
[20:53:09] <sayrer> HTTP Was Already Widely Deployed Before 2616
[20:53:25] <sayrer> - Things that were impossible then are still impossible now
[20:53:29] <sayrer> Some non-goals
[20:53:42] <sayrer> - Don't try to help naive readers understand the spec
[20:53:50] <sayrer> - It's not a textbook or tutorial
[20:53:59] <sayrer> Don't try and make HTTP a better protocol
[20:54:09] <sayrer> - Great idea, just not this working group
[20:54:36] <sayrer> Don't try to make HTTP better for other applications
[20:54:55] <sayrer> - avoid tunneling considerations (there are other protocols...)
[20:55:12] <sayrer> Don't try to change the behavior of current implementations
[20:55:23] <sayrer> - They probably won't change
[20:55:46] <sayrer> Don't try to put messes back in the bottle
[20:55:53] --- jack.bates has joined
[20:56:02] <sayrer> - don't pick winners for competing interpretations
[20:56:21] <sayrer> - don't add conditionals for every possibility
[20:56:26] <sayrer> So What's The Point
[20:56:38] <sayrer> - Keep new implementations from making things worse
[20:56:57] <sayrer> Interoperability Testing
[20:57:10] <sayrer> - What's an HTTP feature?
[20:57:18] <sayrer> - Very hard to judge
[20:57:29] <sayrer> - Focus on testability of specification
[20:58:01] <sayrer> Progressing To Standard
[20:58:14] <sayrer> - More widely deployed and more mature than many IETF Full Standards
[20:58:28] <sayrer> - Don't get hung up on IETF process
[20:58:44] <sayrer> - Remove broken stuff
[20:58:54] <sayrer> - Document interop and deployment
[20:59:19] <sayrer> Next Agenda Item
[20:59:40] <sayrer> Charter Review and Process Review
[21:00:13] <sayrer> Mark Nottingham: review of WG charter
[21:00:18] --- sftcd has joined
[21:00:37] <sayrer> http://www.ietf.org/html.charters/httpbis-charter.html
[21:01:20] <sayrer> Mark Nottingham: The security deliverable is a compromise
[21:01:36] <sayrer> Mark Nottingham: We're not here to invent a new security mechanism
[21:02:10] <sayrer> Mark Nottingham: we're not here to add things (unless something major occurs--would be surprising)
[21:02:36] <sayrer> Mark Nottingham: Charter doesn't constrain document count
[21:02:45] <sayrer> Mark Nottingham: schedule review
[21:03:01] <sayrer> Mark Nottingham: schedule is aggressive, focus on minor updates to spec make this possible
[21:03:17] <sayrer> Mark Nottingham: [Note Well text]
[21:03:33] <sayrer> Mark Nottingham: Opening HTTP Issues
[21:03:46] <sayrer> Mark Nottingham: - Send mail with NEW ISSUE in the subject
[21:04:09] <sayrer> Mark Nottingham: - Will be added if it's clearly in-scope
[21:04:17] <sayrer> Mark Nottingham: Closing Issues
[21:04:43] <sayrer> Mark Nottingham: Editiorial Issues handled by editors, WG reviews
[21:04:54] <sayrer> Mark Nottingham: Design Issues have a more formal process
[21:05:06] <sayrer> Mark Nottingham: - Propose resolution
[21:05:11] <sayrer> Mark Nottingham: - Consensus
[21:05:21] <sayrer> Mark Nottingham: chair decides
[21:05:41] <sayrer> Mark Nottingham: - Incorporation (editors incorporate)
[21:05:59] <sayrer> Mark Nottingham: Verification (WG)
[21:06:23] <sayrer> Roy Fielding: consensus of people who just show up on the list doesn't work
[21:06:41] <sayrer> Roy Fielding: consensus of implementations works
[21:07:02] <sayrer> Mark Nottingham: agree, I have no intention of measuring by vote on mailing list
[21:07:53] <sayrer> Kurt Zelinga: does market share count?
[21:07:58] <sayrer> Mark Nottingham: well, that's more complicated
[21:08:22] <sayrer> Doug Otis: interop isn't just a simple client/server issue anymore
[21:08:39] <sayrer> [scribe misses]: issue on detail of slide
[21:08:53] <sayrer> Mark Nottingham: chair can make proposals
[21:08:55] --- stephen.morris has left
[21:09:00] <sayrer> Mark Nottingham: Drafts As Checkpoints
[21:09:20] <sayrer> Mark Nottingham: Each draft will have - summary of issues closed, diffs
[21:09:56] <sayrer> Mark Nottingham: interim meetings
[21:10:10] <sayrer> Mark Nottingham: proposes weekly(?) meetings
[21:10:35] <sayrer> Paul Hoffman: progress is as easy to make on mailing list
[21:10:45] <sayrer> Mark Nottingham: not a lot interest here in telcons
[21:10:57] <sayrer> Larry Masinter: maybe reserve a slot in case it's needed
[21:11:25] <sayrer> Mark Nottingham: the other problem is the geographic split (timezones...)
[21:12:01] <sayrer> Mark Nottingham: Balachander Krishnamurthy quote
[21:12:18] <sayrer> [quote focuses on testing]
[21:12:44] <sayrer> Mark Nottingham: next agenda item: draft-lafon review (Yves Lafon)
[21:13:07] <sayrer> Yves Lafon: let's make this short, already did a presentation last IETF meeting
[21:13:27] <sayrer> Yves Lafon: Two previous attempts to revive the spec
[21:13:43] <sayrer> Yves Lafon: many people asking questions about small details on the mailing list
[21:14:16] <sayrer> Yves Lafon: [summary of draft-lafon history]
[21:14:26] <sayrer> Yves Lafon: March 2007 strawman charter
[21:14:53] <sayrer> Yves Lafon: November 2007, rfc2616bis-04
[21:15:03] <sayrer> Yves Lafon: started with cosmetic changes only
[21:15:12] <sayrer> Yves Lafon: established root for paper trail
[21:15:52] <sayrer> Yves Lafon: incorporated changes from draft-gettys, a previous revision attempt
[21:16:15] <sayrer> (some of them, some just added to the list)
[21:16:38] <sayrer> Yves Lafon: -04 draft has mostly editorial changes
[21:16:49] <sayrer> Yves Lafon: continued with monolithic approach
[21:16:59] <sayrer> Yves Lafon: contrast with Roy's approach
[21:17:37] <sayrer> Mark Nottingham: thanks Yves
[21:17:56] <sayrer> Mark Nottingham: Yves and Julian have produced one doc, the other proposal we have is from Fielding
[21:18:05] <sayrer> Mark Nottingham: this is a blocking issue, and needs to be resolved
[21:18:35] <sayrer> Mark Nottingham: can't resolve issues until we have a WG doc
[21:19:00] <sayrer> Mark Nottingham: need to choose between Roy's split approach and the monolithic document
[21:19:21] <sayrer> Mark Nottingham: need to gauge opinion here, and then take it to the mailing list
[21:19:39] <sayrer> Mark Nottingham: Roy Fielding will present
[21:20:06] <sayrer> Mark Nottingham: these didn't exist until recently, helps to have concrete documents
[21:20:49] <sayrer> Roy Fielding: http://labs.apache.org/webarch/http/draft-fielding-http/
[21:21:20] <sayrer> Roy Fielding: any Apache committer can update this (including Julian Reschke)
[21:21:58] <sayrer> Roy Fielding: first tackled framing and message parsing
[21:22:17] <sayrer> Roy Fielding: meaning of headers, methods, status codes is draft #2
[21:22:33] <sayrer> Roy Fielding: #3 concerns message payload and content negotiation
[21:22:46] <sayrer> Roy Fielding: the rest are optional features of HTTP
[21:23:14] <sayrer> Roy Fielding: 4) conditionals, 5) Ranges, 6) Caching
[21:23:47] <sayrer> Roy Fielding: 7) Access Authentication. Not sure where to work on this, I think this group should do it.
[21:24:05] <sayrer> Roy Fielding: last time we split it off, it didn't work so well. They went and worked on S-HTTP
[21:24:16] <sayrer> Roy Fielding: experience shows no other WG cares about 2617 mechanisms
[21:24:38] <sayrer> Roy Fielding: 8) cookies. Useful to think of cookies as part of HTTP
[21:25:13] <sayrer> Roy Fielding: Gear the reader towards their tasks, e.g. message parsing implementors are different from those working message semantics
[21:25:56] <sayrer> Roy Fielding: experience with previous revisions shows that once the document reaches a particular size, people stop reviewing the whole of the document
[21:26:32] <sayrer> Roy Fielding: if a header changes, a reviewer focused headers doesn't review corresponding changes on caching, for example
[21:27:00] <sayrer> Roy Fielding: large documents lead to RFCs with *many* editorial errors
[21:27:35] <sayrer> Roy Fielding: want to see all implementation interoperate according to design, not just in an ad-hoc manner
[21:28:00] <sayrer> Roy Fielding: maintaining to issues lists
[21:28:18] <sayrer> Roy Fielding: one is Julian/Yves', other is specific to draft-fielding-*
[21:28:26] <sayrer> [two issues lists]
[21:28:48] <sayrer> Roy Fielding: combined table of contents is available
[21:28:57] <sayrer> http://labs.apache.org/webarch/http/draft-fielding-http/outlineALL.html
[21:29:33] <sayrer> Roy Fielding: RFC 2616 outline available. links point to individual portions of the partitioned drafts
[21:29:45] <sayrer> http://labs.apache.org/webarch/http/draft-fielding-http/outline2616.html
[21:29:55] <sayrer> Roy Fielding: Jira issues list
[21:30:02] <sayrer> http://issues.apache.org/jira/browse/HTTPDRAFT
[21:30:19] <sayrer> Roy Fielding: has features that let us split work
[21:30:50] <sayrer> Roy Fielding: might be possible to plan the next revision in Jira as well
[21:31:45] <sayrer> Paul Hoffman: Do you plan to rev all of the documents at the same time?
[21:31:58] <sayrer> Roy Fielding: the first set would all go out at the same time
[21:32:29] <sayrer> Roy Fielding: as soon as we get through the first tasks, we good delegate to more people
[21:32:34] <sayrer> could delegate
[21:32:48] <sayrer> Roy Fielding: many process alternatives to allow more editors
[21:32:59] <sayrer> Roy Fielding: we can do more in parallel with multiple documents
[21:34:00] <sayrer> Mark Nottingham: once people see the drafts, they tend to like the drafts. Is that reflected here? Interested in more opinions.
[21:34:24] <sayrer> David Morris: the principle seems nice, appreciate the work. Concerned that we can verify that it represents the same content.
[21:34:43] <sayrer> Mark Nottingham: We did generate diffs. It's not pretty, but it is possible to verify.
[21:35:17] <sayrer> Mark Nottingham: I think the diffs are a viable way to check that the documents represent the same protocol.
[21:35:59] <sayrer> Paul Hoffman: I was concerned that new developer would have trouble with the partitioned documents. Having read them, I think this will be fine.
[21:36:39] <sayrer> Paul Hoffman: Concerned that it will be easy for a topic in one draft to change another document.
[21:37:09] <sayrer> Paul Hoffman: maybe rev all of the documents at once to avoid juggling issues
[21:37:57] <sayrer> Larry Masinter: he's asking for full snapshots. might not be useful, but it's not hard.
[21:38:07] <sayrer> Cyrus Daboo: how many cross-references are there?
[21:38:37] <sayrer> Roy Fielding: there are very few cross-references. that's how the partitioning decisions were made.
[21:39:12] <sayrer> Roy Fielding: the caching doc has many, but in 2616 the caching section restates other sections. this is not helpful
[21:39:34] <sayrer> Cyrus Daboo: can we put it all back together at the end
[21:39:36] <sayrer> ?
[21:39:54] <sayrer> Roy Fielding: my opinion is that what's good for the editors is good for the reader
[21:40:03] <sayrer> Roy Fielding: WG can change its mind
[21:40:30] <sayrer> Mark Nottingham: been running a personal experiment using Fielding docs. Works well.
[21:40:53] <sayrer> Mark Nottingham: Julian working on tool to help with references
[21:41:07] <sayrer> Cyrus Daboo: does this create profiles?
[21:41:27] <sayrer> Mark Nottingham: I don't think the Fielding documents take a stance on this
[21:41:50] <sayrer> Roy Fielding: there are optional features of HTTP, these are split out
[21:42:12] <sayrer> Cyrus Daboo: this could help testability as long as there aren't too many references
[21:42:54] <sayrer> Kurt Zelinga: does the reorganizing the documents help clarify interoperability problems?
[21:43:07] <sayrer> Roy Fielding: yes, because people don't read all of 2616
[21:43:29] --- arifumi has left
[21:43:29] <sayrer> Roy Fielding: people assume that optional features are required (e.g. content negotiation)
[21:43:52] <sayrer> Larry Masinter: I think this is a good idea.
[21:44:37] <sayrer> R Sayre: been able to resolve args with the partitioned documents
[21:44:51] <sayrer> Mark Nottingham: not a big fan of hums, but here we go
[21:45:09] <sayrer> Mark Nottingham: can we take this to the mailing list and a get a resolution
[21:45:11] <sayrer> ?
[21:45:37] <sayrer> Larry Masinter: editors and chairs have some discretion
[21:45:48] <sayrer> Mark Nottingham: yeah, but this a large change
[21:47:05] --- arifumi has joined
[21:47:32] <sayrer> Mark Nottingham: Robert: please record that their is consensus in the room that addressing the problem's in Roy's presentation would be useful
[21:48:05] <sayrer> Mark Nottingham: next step, check the mailing list
[21:48:58] <sayrer> Mark Nottingham: Next Agenda Item: issues list items
[21:49:15] <sayrer> Mark Nottingham: first up is i36 ABNF
[21:49:51] <sayrer> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i36
[21:50:36] <sayrer> Julian Reschke: RFC2616 uses 822-derived BNF with extensions
[21:50:55] <sayrer> Julian Reschke: can't parse with BNF parser
[21:51:26] <sayrer> Julian Reschke: need to have custom LWS rule to interpret
[21:52:07] <sayrer> Julian Reschke: doing verification with Bill Fenner's ABNF parser (BAP)
[21:52:36] <sayrer> Julian Reschke: automated diffs and verification between BNF of each drafts
[21:52:44] <sayrer> Julian Reschke: discovered many bugs in 2616 BNF
[21:53:31] <sayrer> Julian Reschke: summary of BNF issues in 2616
[21:53:57] <sayrer> Julian Reschke: including prose rules and attempts to use BNF that do not work
[21:54:16] <sayrer> Julian Reschke: BNF is now passing with zero errors
[21:54:41] <sayrer> Julian Reschke: next steps--language tags and language rules (currently obsolete reference)
[21:55:21] <sayrer> Julian Reschke: probably want to refer to the other RFCs on language tags and ranges
[21:55:22] --- hardie@jabber.psg.com has joined
[21:55:54] <sayrer> Julian Reschke: HTTP URL needs update to RFC3986
[21:56:15] <sayrer> Julian Reschke: some specific problems:
[21:56:31] <sayrer> Julian Reschke: 1) What do with list/rule conversion?
[21:56:45] <sayrer> Julian Reschke: 2) What to do with implicit LWS?
[21:57:10] <sayrer> Julian Reschke: 2) is probably a harder decision
[21:57:29] --- Aki Niemi has joined
[21:57:34] <sayrer> Mark Nottingham: these last two are blocking the ABNF conversion. Any discussion?
[21:58:09] <sayrer> Roy Fielding: My suggestion is to get rid of the pound-sign syntax.
[21:58:38] <sayrer> Roy Fielding: Have the 'Allow' field defined as something like allow-field-value instead of #Method
[21:58:59] <sayrer> Roy Fielding: essentially, replace the pound-sign shorthand with an extra rule shorthand
[21:59:49] <sayrer> Roy Fielding: need to remove unlimited LWS, it's a DoS attack anyway
[22:00:08] <sayrer> Mark Nottingham: there's a seperate issue for that (i30)
[22:00:45] <sayrer> Keith Moore: I have a hard accepting a compatibility change like this
[22:00:53] --- rdenisc has joined
[22:01:13] <sayrer> Roy Fielding: I agree with that, but this doesn't pose a compatibility problem. If one occurs, we'll have to revisit.
[22:01:27] <sayrer> Keith Moore: hard to survey all implementations
[22:02:07] <sayrer> Keith Moore: this would be impossible in email
[22:02:30] <sayrer> Roy Fielding: HTTP can take this kind of change
[22:03:17] <sayrer> David Morris: I don't think we really know what's out there... lots of impls could be lenient
[22:03:56] <sayrer> Paul Hoffman: in 2822 we had an obsolete grammar and a new one. seemed like a good idea...
[22:04:50] <sayrer> Paul Hoffman: WG needs to make a rule about getting rid of ridiculous stuff. Impementors haven't been happy with accept grammars, etc.
[22:05:24] <sayrer> Paul Hoffman: does obsolete/non-obsolete grammar cause pain?
[22:05:24] --- rdenisc has left
[22:05:43] --- guenther has left
[22:05:50] <sayrer> [various opinions in room]
[22:06:14] <sayrer> Mark Nottingham: should we be working on BNF readability?
[22:06:31] <sayrer> Kurt Zelinga: concerned that BNF conversion discussion shifted to technical change
[22:06:41] <sayrer> Keith Moore: two observation about BNF:
[22:06:56] <sayrer> Keith Moore: conversion to ABNF will hurt readability
[22:07:49] <sayrer> Keith Moore: it seems like ABNF should be usable to generate a parser, but people end up writing them ad-hoc
[22:08:18] <sayrer> Mark Nottingham: charter says we should update to ABNF. might be that the result is hard to read.
[22:08:45] <sayrer> Mark Nottingham: LWS issue is seperate: i30
[22:09:09] <sayrer> Larry Masinter: sometimes you need a grammar for writers and a grammar for readers
[22:09:33] <sayrer> Larry Masinter: correctness can be more important than simplicity/readability
[22:09:57] <sayrer> Mark Nottingham: Julian, is the path clear?
[22:10:03] <sayrer> Julian Reschke: no
[22:10:30] <sayrer> Mark Nottingham: need to defer LWS to issue i30
[22:11:07] <sayrer> Mark Nottingham: maybe we need to convert to ABNF mechanically
[22:11:20] <sayrer> Roy/Julian: it's editorial. try it, have the list check it
[22:11:50] <sayrer> Mark Nottingham: Issue i30
[22:12:06] <sayrer> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i30
[22:14:10] <tonyhansen> Mark Nottingham: is space before colon a security issue? RFielding: yes, but a lame one
[22:14:45] <tonyhansen> yngve: ??
[22:15:04] <tonyhansen> phil guenther: one of key splits btw generate/accept grammer in 822
[22:16:06] <tonyhansen> phil guenther: need to clamp down on people who think different and file bug reports
[22:16:47] <tonyhansen> rfielding: put LWSP every place it should go and use BWSP (for "bad") in places it should not be, giving combined grammar
[22:17:08] <tonyhansen> larry: thinking same thing; calls out DoS attacks
[22:17:34] <tonyhansen> keithmoore: if only diff btw accept/gen grammar is white space, that's good
[22:18:14] --- hardie@jabber.psg.com has left
[22:18:14] <tonyhansen> phil guenther: disagree w/ para "the wording explicit..."
[22:18:43] <tonyhansen> jruschke: forgot the point about collapsing strings
[22:19:17] <tonyhansen> marknottingham: trust editors to do it? concensus: yes
[22:19:56] <tonyhansen> larry: can introduce additional terminals to help it look better
[22:20:19] <tonyhansen> phil: # of bugs in 2822 because "bos" was tacked on in 3 diff levels and became a nightmare
[22:20:52] <tonyhansen> mark nottingham: what about LWS before field name?
[22:21:17] <tonyhansen> mark nottingham: special case for 1st line?
[22:21:21] <tonyhansen> thoughts?
[22:21:41] <tonyhansen> larrymasinter: doc what is, not what should be, then focus on new implementors
[22:22:52] <tonyhansen> larry: what do clients need to do to interoperate a lot of this may not matter much, say "don't put spaces there" segment the audience in favor of implementors, may make things easier
[22:23:32] <tonyhansen> mark: any strong feelings on this issue
[22:24:13] <tonyhansen> yngve: the parameter syntax, is LWS permitted between attribute name and "=", it's a similar issue
[22:24:30] <tonyhansen> issue 74: header value i18n
[22:25:23] <tonyhansen> mark: 2612 says headers must use iso8859 or rfc 2047
[22:25:40] <tonyhansen> mark: this is unnecessarily complex, not necessarily followed by implementatiosn
[22:27:20] <tonyhansen> yngve: encoding in headers, 2047 has been usefule for old header values but where you have attributes, need to use rfc 2031 paul: does 2616 say that? yngve: no, but says 2047 only for non-attributes, so an issue
[22:28:19] <tonyhansen> julian: lots of interop problems if we can't make it better, by restricting to 8859-1 or using escaping, need to have examples shown
[22:28:43] <tonyhansen> mark: wants called out explicitly which headers take which encodings
[22:29:36] <tonyhansen> keithmoore: 2047 only for things purely for human reading, has very narrow applicability, mark: should be few uses
[22:29:57] <tonyhansen> paul: yngve, please point out on list where this comes up
[22:30:06] <tonyhansen> mark: will discuss on list
[22:30:30] --- hta has joined
[22:31:15] <tonyhansen> yves: in case of encoding, you have byte stream, base64 may hide it (??)
[22:33:49] <tonyhansen> issue 20: default charsets for text media types many media types have own defaults how do these interact w/ http's default larry: document the confusion that occurs when no charset is provided barry leiba: you're in another area where you're using email-specific things in non-email area, add a SHOULD to help mark: most servers don't, may be site policy but that's not followed
[22:35:47] <tonyhansen> keith: this may break existing implementations, need to specify what's supposed to happen, not to create a compatibility problem, the goal is to raise the bar and narrow the spec, 2 concepts: here's what it takes to interop, and here's what it takes to be compliant barry: except a goal here is to advance in standards process, so can't break things
[22:36:05] <tonyhansen> keith: but you can cut out features, not add
[22:36:38] <tonyhansen> sayer: in firefox, we broke things when we added charset, so we pulled it back out
[22:37:05] --- arifumi has left: Disconnected
[22:39:58] <tonyhansen> larry: don't get hung up w/ details : do the right thing this area is something that does work in practice, the body usually has the content-type if the header doesn't, this may be a place where following practice may be okay and if you write a new client you need to know that, not supplying the content type works pretty well mark: most clients ignore the charset if there's a conflict with the body, would like to eliminate the requirement (not add a new requirement)
[22:40:23] <tonyhansen> keith: the principle is "must not lie, must not make up info for the meta data"
[22:41:04] <tonyhansen> yngve: back to 2047 issue, found the reference, 2047 syntax must not be used for parameter mark: send that ref to the list
[22:43:07] <tonyhansen> ??: for some encodings, there's a script tag, sometimes it disappears, not a good idea to specify html content in http, should encourage use of either: charset in http or charset within html
[22:43:41] <tonyhansen> mark: can add a disclaimer larry: complicated and needs to go to the list
[22:43:58] <tonyhansen> stopping for the evening
[22:43:59] --- sftcd has left
[22:44:11] --- Barry Leiba has left
[22:44:13] --- doug.otis@gmail.com has left
[22:44:16] --- tlyu@jis.mit.edu has left
[22:44:17] --- tonyhansen has left
[22:45:16] --- sayrer has left
[22:45:24] --- hta has left
[22:46:22] --- randy has left
[22:46:35] --- cyrus_daboo has left
[22:46:50] --- Aki Niemi has left
[22:47:04] --- jack.bates has left
[22:49:18] --- aaronstone has left
[22:57:52] --- hta has joined
[22:59:52] --- mnot has left
[23:02:19] --- hta has left
[23:04:27] --- julian.reschke has left