This is the recent traffic on the #SPF-council IRC channel on irc.pobox.com. Anyone may join the channel, but only council members can talk.

If you do not have access to IRC, you may view the recent traffic at: http://www.schlitt.net/spf/spf-council/now/irc_log.html.

This log can be can be viewed at: http://www.schlitt.net/spf/spf-council/2006/05/06_irc_log.html.

IRC nicknames:
JulianJulian Mehnle
MarkKMark Kramer (asarian-host.net)
SDGathmanStuart Gathman
shewMark Shewmaker
willixWilliam Leibzon
 
freesideMeng Weng Wong
gconnorGreg Connor
grumpyWayne Schlitt

--- Sat May 6 16:06:10 UTC 2006 ---
16:06<SDGathman>Am I mixed up on time?
16:19<Julian>SDGathman: We're T - 41min
16:28<SDGathman>Ok. DST caught me.
16:29<Julian>:-)
16:30<Julian>William sent me an e-mail: "If I'm not there at/close to the meeting start, send email to william-<xxx>@elan.net (this will end up going to my cell phone)." I wonder what this is supposed to mean.
16:32<SDGathman>His cell phone has text messaging, but not a scheduler.
16:32<Julian>I didn't know that.
16:33<SDGathman>That is just my guess - you asked what it meant.
16:33<SDGathman>By sending the email, his cell phone will vibrate/make noise.
16:34<Julian>So I guess we should send him a message at T - 10min or so...
16:34<SDGathman>But does his cell service check SPF?
16:34<Julian>Heh...
16:40<Julian>mail.elan.net runs Sendmail, so perhaps it does...
16:52<Julian>I sent the mail.
17:00<Julian>hi shew!
17:01<shew>Hello Julian.
17:02<shew>Glad you called the meeting, btw. Not that I particularly have anything to discuss, (other than contributing to general excitement about 4408), but we were going for a while without one.
17:03<Julian>shew: I know. :-( I should have made a point of $topic, "4. Coordinating efforts to implement the project agenda" earlier.
17:03<Julian>I was busy with other things, so I procrastinated.
17:04<shew>I quite understand being busy.
17:04<Julian>wait(William || MarkK)
17:06<Julian>w00t!
17:06<Julian>We have quorum.
17:06<Julian>Shall we start?
17:07<SDGathman>ok
17:07<shew>sure
17:07<Julian>Ok, please review the meeting agenda ($topic). Any additions?
17:08<shew>Thumbs-up here.
17:09<Julian>I assume none. So let's start.
17:09<willix>agenda is fine
17:10<Julian>One thing first. willix, what are your plans on the meeting minutes? Please understand that it is essentially _your_ decision whether/how/when you want to write them. I'd just like to know your plans.
17:11<willix>I still plan to write them but never get around to that
17:11<Julian>I hadn't written the minutes for several months last year when I was the secretary, and I'm still missing a few, so I'm hardly in a position to complain. ;-)
17:11<willix>I probably should not have volunteered for secretary duties but at the time I did my schedule for next few months was not so busy
17:12<Julian>willix: Please ask for help if you need it.
17:12<Julian>Ok, let's start really.
17:12<Julian>1. Reports.
17:12<willix>One of the projects I'm involved in will end in May which will free up 20 hours/week
17:12<Julian>I'll start with my report.
17:13<Julian>I guess you all know that RFC 4408 is out. I wonder why S-ID has gotten the numbers 4406/4407, but, oh well...
17:14<willix>yes, that was strange that document that others refer to is highier rfc
17:14<Julian>I have begun to update the RFC's source XML file with the RFC Editor's changes and our AUTH48 changes in order to be able to generate a HTML file of the final document.
17:15<Julian>I'm virtually finished with that, but there are some oddities with xml2rfc <http://xml.resource.org> that are keeping me from finishing it.
17:15<willix>btw it maybe of interest to know that the reason MS was pushing us before is to announce about RFC on the authentication summit2
17:16<Julian>Interesting. I hope you can elaborate on that in a few minutes.
17:16<willix>publication of RFCs missed by 2 weeks
17:16<Julian>For those interested, I used xml2rfc 1.31pre5 and have also used rfcdiff <http://tools.ietf.org/tools/rfcdiff/> in the process. Very useful.
17:17<SDGathman>SMTP AUTH is incredibly important for deploying SPF.
17:17<SDGathman>But MS clients are buggy wrt AUTH.
17:18<Julian>On another note, I finally completed a release of the website software. It has brought us a few new features including anchors support. As a result, the FAQ on the new website has been switched live.
17:18<shew>Nice!
17:18<willix>good
17:18<Julian>Koen and I have done some work on the new website <http://new.openspf.org/Recent_Changes>.
17:19<Julian>I plan to write the "Introduction" page later today or tomorrow. A few more things will have to be done before we can switch the new website live, see the project agenda.
17:19<Julian>I can't think of anything else to report.
17:19<Julian>Who wants to report next?
17:20<SDGathman>Is my experience getting users to use SMTP AUTH appropirate?
17:21<Julian>I agree that SMTP AUTH is essential.
17:21<SDGathman>I am keeping notes about problems with various clients.
17:21<Julian>I have little experience with whether people resist to using it.
17:22<SDGathman>The users don't resist at all.
17:23<SDGathman>It is just that I discover when they are in Costa Rica that their particular version of Outlook or Thunderbird is broken wrt whatever.
17:23<willix>with all the changes so new.openspf.org how close are we to finishing it?
17:24<Julian>willix: Well, based on the loose collection of outstanding tasks on <http://new.openspf.org/Project_Agenda>...
17:24<Julian>...I think we may be able to go live within the next two weeks.
17:26<willix>I'm thinking it would be nice to make an announcement about RFC with new site or at the very least to have a link there to a new SPF beta site to go live within next couple weeks
17:26<Julian>I think we should "try to say more with less words" on the website. The FAQ is quite extensive, but it answers many things that should be explained by a semi-short introduction page, for example.
17:27<Julian>I like the Mozilla website for its brevity.
17:27<shew>I just started a new contract job this Monday, doing sysadmin work with a company that does email outsourcing. (When I heard about the company and the opening, my first thought "spammer", but after a lot of discussion I was convinced that was not true, though their customers might sometimes be confused and have to be continually educated on best-practice stuff.) The upshot is that I'll become exposed to two interesting things: Fir
17:27<shew>stly, I'll find out about how well-meaning but partially-technically confused folks might try to spam without understanding their errors, and secondly since we use spf, I'll become exposed to more real-life failure modes.
17:28<SDGathman>Heh - I get plenty of real-life failure modes.
17:28<shew>(On the second point, just this week I noticed a problem with include:'ing a domain that doesnt' have an spf record.)
17:28<SDGathman>Yep - permerror.
17:29<Julian>BTW, I noticed (during updating the announcement draft) that both the old and the new website lack a page on "SPF vs. Sender-ID". I think it is now time to explain the technical conflict and give some recommendations.
17:29<shew>I'm sure you do. :-)
17:29<Julian>shew: What's the include:non-existent-domain problem?
17:30<Julian>s/non-existent-domain/domain-w/o-spf-record/ # Doh...
17:30<Julian>(I keep confusing the two...)
17:30<willix>touchy subject
17:30<shew>Julian: if example.com has as an spf record: "v=spf1 a mx include:friend.example.com -all", but friend.example.com has no spf record, then spf evaluations of example.com return a permerror.
17:31<shew>That's what I was referring to.
17:31<SDGathman>Yep.
17:31<Julian>Yeah, that might be one of the things worthy to be fixed in a SPF++.
17:31<shew>Hmm. Maybe we need to come up with good terms for common errors, as opposed to long, convoluted sentences.
17:32<Julian>shew: You mean wrt the FAQ?
17:32<shew>Julian: I agree.
17:33<Julian>willix: Can you elaborate on the authentication summit / RFC thing? Do you know more about that? Did you attend the summit?
17:33<shew>Julian: That, and elsewhere. I'm just thinking marketing-type stuff. (Such as referring to logical fallacies by name. "Argument by authority".)
17:33<Julian>shew: Interesting idea. Please pursue it.
17:33<willix>I did not but have talked to few folks
17:34<shew>Will try. :-)
17:34<shew>Anyway, no more reports here.
17:34<willix>The larger of my current contracts is with company that sends a lot of emails....
17:35<willix>Sometimes several million a day and all solicited and watned by users.
17:35<willix>But anyway one of the people there I talked to and also independed from that somebody else
17:35<shew>willix: Then you and I probably have similar issues. (Making sure that we're not supporting intentional spammers, educating confused clients, etc.)
17:36<willix>Microsoft still continues to push Sender-ID and did a lot of marketing before that summit
17:37<SDGathman>"Missing include"
17:37<willix>Their current focus is getting large companies (Fortune 500, etc) to adapt it and they claim 20% penetration there
17:38<willix>If I understand they really really wanted to say SID is RFC now on the summit
17:38<Julian>Except for the inappropriate "v=spf1" re-use, we have little reason to hate S-ID. I wonder however where those deployment numbers come from. Is that real S-ID implementations, or is it "just" SPF?
17:39<Julian>Well, _we_ didn't block the RFC. It was beyond our control, mostly.
17:39<willix>I don't know but unfortunetly most of the people in the "industry" dont care
17:40<Julian>It's ok that they don't care. If they abuse v=spf1 records that weren't published with PRA in mind, then it will be _them_ who got the problems.
17:40<willix>I know we did not block it. I was just trying to explain why Meng was trying to push us and you correct saw that it was probably MS pushing him. They wanted more publicity and to co-incide that with their summit
17:41<Julian>Understandable. I guess they have invested significantly into S-ID.
17:41<willix>If you do seach on "Sender ID" on google news you will easily see all that too
17:41*Julian searches for "Sender ID" on Google News.
17:42<willix>The problem I saw when talking to few folks about differences is:
17:42<willix>1. Most people have close to 0 idea of differences between SMTP header fields and SMTP session parameters
17:42<Julian>*sigh* MS are still marketing S-ID as anti-spam. Damn them for that!
17:43<Julian>"How many fingers are you seeing?"
17:43<willix>(that btw includes technical folks like CTO and IT managers - trying to explain to end-users is almost impossible)
17:44<Julian>Oh, I have succeeded many times in that by using the snail-mail "envelope -- letter head" analogon.
17:44<Julian>(Sorry, didn't want to interrupt you.)
17:44<willix>2. Most folks want authenication solution that works for their "From" identity not understanding what that means and how its used
17:44<SDGathman>I just tell users that SPF validates "Return-Path" and SID validates some other header.
17:45<willix>3. They want something that just works with as little effort for them to use it as possible
17:45<SDGathman>They both just work - but mail clients don't tell them which header is validated.
17:46<SDGathman>At least with SPF, it is the same one every time.
17:47<Julian>willix: Thanks for the explanation.
17:47<willix>After a meeting a few folks I kind of began to understand why and how MS is able to push SID. It is not as self-serving as I thought, they just have good marketing/business people who understand well what businesses are expecting
17:47<willix>And their technical folks are there to respond with modo that if it soft-of works, its good enough
17:48<willix>and marketing and business folks will do the rest
17:49<willix>Anyway, sorry for this long text. Lets get on with council business
17:49<Julian>(The question is, will the product MS is "selling" solve a real problem?)
17:49<Julian>Ok, any further reports? If so, type "..." quickly.
17:50<Julian>2. Announcement and press release.
17:50<Julian>Any comments on the latest announcement draft?
17:51<Julian>willix said that he'd prefer the new website to be "finished" before we make the announcement, however I don't think that's realistic w/o waiting much longer.
17:52<Julian>I think we need to make the announcement ASAP, or the RFC will be old news.
17:52<willix>A good alternative I see is have a link to it saying its a new beta site that we expect to finish in the next 30 days
17:53<Julian>We could always make another (very brief) announcement as soon as the website is done.
17:53<willix>BTW - I agree about announcement going ASAP. Its more important than anything else
17:55<Julian>Any further comments? On the announcement text?
17:55<shew>I also agree about announcement going asap.
17:55<shew>And consider me to have a standing vote for the website going live. :-)
17:55<Julian>Well, we need man power to work on the website.
17:56<Julian>We needed man power all along, that's why it has taken so long.
17:56<Julian>(among other reasons)
17:58<Julian>The announcement needs two more pages before it can go out: "Contact" (or something), and "SPF vs Sender ID"
17:58<Julian>As I said, I'll work on the "Introduction" page and the contact form module for the "Contact" page.
17:58<willix>explain why it needs more pages
17:59<Julian>See the announcement draft. It has these two references, which I don't think we should omit.
18:00<willix>the draft is in email sent to council list or do you have it online?
18:00<Julian>The former.
18:01<Julian>It's online, too, in the spf-council archives: http://archives.listbox.com/1943/200605/0003.html
18:05<willix>This is already pretty long. Which sections or separate pages did you want to add?
18:05<SDGathman>"Microsoft's SPF mutation" sounds unnecessarily negative.
18:06<Julian>willix: I didn't want to add anything to the announcement itself.
18:06<SDGathman>Our only complaint is the record reuse.
18:06<Julian>willix: Did you read my spf-council message with the announcement in it? It explains the need for the two website pages before the announcement text.
18:07<Julian>SDGathman: Well, evolution works by mutation. I don't see any negative connotation in "mutation".
18:08<Julian>I might concur wrt "mutant". But I think "mutation" is ok, don't you think?
18:08<willix>yes, I read it
18:08<willix>Contact-US page is easy to add. SID vs SPF is tricky as not to offend too many people
18:09<Julian>willix: How could explaining the technical differences be offensive?
18:09<Julian>The day I am unable to tell the objective truth because people might feel offended, I'll quit immediately.
18:10<Julian>(...not meaning that it is necessarily _me_ who should write the "SPF vs S-ID" page.)
18:10<willix>Explaining technical differences is not.
18:10<SDGathman>I could write an SPF vs S-ID draft.
18:11<SDGathman>The goal is neutral POV except for record reuse.
18:11<Julian>SDGathman: I concur.
18:11<willix>The problem is that while you can explain the differences to technical community a lot of other folks would not get it
18:12<Julian>SDGathman: Cf. the IESG appeal.
18:12<Julian>willix: So?
18:12<willix>saying that MS is propriatory protocol they do get, but this is offensive
18:12<SDGathman>As far as spf-council, anyway. The patent issue prevents me from ever implementing S-ID.
18:12<shew>Suggestion: A new.openspf.org/Sitemap/Drafts page of the wiki, not listed on the site map.
18:12<shew>With drafts-in-process linked on the Drafts page.
18:12<Julian>willix: I wouldn't say that the "v=spf1" re-use is in any way proprietary. PRA is, but that's not the issue here.
18:13<Julian>shew: Nah, just create pages but don't create links to them until they're ready for prime time.
18:13<shew>Okay.
18:14<shew>I'll push for Drafts later then, when we have lots of drafts going at once.
18:14<willix>BTW - we do have http://old.openspf.org/OpenSPF_community_position_v102.html
18:14<Julian>You can always make a page private by saying "#PRIVATE" in its first line.
18:14<shew>What does it mean to be private?
18:14<shew>That only logged-in members can see it?
18:15<Julian>willix: Yes, we do. But that's mostly separate from the "SPF vs S-ID" page I was talking about.
18:15<Julian>shew: Yes, exactly.
18:15<shew>Then /Drafts can be private too. :-)
18:15<willix>The reason I brought it up is that its good at both technical and non-technical issues, it is however somewhat offensive
18:15<Julian>But why make it a sub-page of "Sitemap"?
18:15<shew>I retract my retraction.
18:16<Julian>willix: I agree that the community position is slightly non-NPOV.
18:16<shew>No, I suggested that it not be on the sitemap, just a plain /Drafts page, for this sort of work-in-progress.
18:16<shew>oh.
18:16<shew>duh.
18:16<shew>thanks.
18:16<shew>I cut&paste error. I meant new.openspf.org/Drafts
18:16<Julian>I see.
18:18<Julian>So, are there any issues with the announcement? Should we s/mutant/derivative/? (I don't think that's necessary.)
18:18<Julian>s/mutation/derivative/, I mean.
18:19<willix>Lets do this - work on additional pages for website this weekend including draft "SPF vs SID" page. If we can not get text that we can agree is good on the council mail list then do not link to it from the announcement
18:19<SDGathman>I second s/mutation/derivative/
18:19<willix>but make announcement next week anyway
18:20<shew>Filling in the ?'s in "Stuart Gathman (?, ??, USA?)"
18:20<shew>Rather, the ?'s need to be filled in.
18:20<SDGathman>Stuart Gathman (Fairfax, VA, USA)
18:20<Julian>Very good, thanks.
18:20<Julian>willix's suggestion sounds like a plan.
18:21<Julian>Motion: Do what willix said @ 18:19 UTC.
18:23<shew>18:22 seconded
18:23<Julian>Votes?
18:23<shew>18:22u seconded, that is.
18:23<shew>18:22u Yes.
18:23<Julian>18:22u: yes
18:23<willix>18:22u: yes
18:24<SDGathman>18:22u: yes
18:24<Julian>So ordered. Thank you.
18:25<Julian>3. What to do about Mark Kramer being AWOL?
18:25<Julian>Quote from my message: "Unfortunately, I have tried and failed to contact Mark Kramer several times over the last 6 weeks. Thus I fear we will have to think about what to do in order to ensure the council's continued operability."
18:25<Julian>Any ideas?
18:26<willix>We had even worth problem with Wayne being AWOL
18:26<Julian>You mean in last fall?
18:27<willix>For finishing the RFC
18:28<Julian>You mean in the last months? True, but the situation was nearly intolerable.
18:28<Julian>(Sorry, Wayne...)
18:28<willix>I think council can bring up a motion that if a council member does not attend 4 meeting in a row (if meetings are held at least two weeks apart) then council can bring up a motion to appoint somebody else in his place if everyone else on the council agrees
18:29<willix>that would be temporary appointment obviously
18:29<Julian>I can try to call MarkK by phone in the next few days.
18:30<Julian>I don't agree that such an appointment can be of temporary nature only, though.
18:30<shew>Could a council member give temporary proxy voting power to someone else in that sort of situation?
18:31<shew>Rather, would that be a workable notion?
18:31<Julian>shew: I don't think that'd be appropriate, unless he gave proxy voting power to the next council candidate in line.
18:32<shew>Hmm.
18:32<shew>Then if that were the case, it's almost hte same as the council appointing someone in his place (temporarily or not). They sort of dovetail to a similar solution.
18:33<Julian>I guess we shouldn't lose too much time over the issue now. I just wanted to bring this up early. I'm going to try to call MarkK on the phone. If I can't reach him before the next meeting, we can still debate what to do.
18:33<willix>We have a system of dealing with it - next person in the list of those people voted is brought in
18:33<willix>Lets discuss it on council email list including proposed remedies
18:34<shew>willix: Is there any speific delay specified in the current system?
18:34<Julian>For the record, the next candidates in line are: Terry Fielder, Alex van den Bogaerdt, Meng Weng Wong.
18:35<willix>there is no "delay" specified right now but many organizations do have system that if somebody does not participate in the activities the other members of same governing group can dismiss him/her
18:35<Julian>shew: No, there is no precedent for replacing a council member by force.
18:36<willix>Typically all this is last resort though and people would try to ask person to resign on his own
18:36<shew>Okay. What I was leading up to is that I would prefer figuring out a system, with the clock not starting to tick until after a system was decided upon.
18:36<Julian>As I said, I don't think this is worth too much time at the moment. For now, let's just hope that MarkK is alive and well, and let's raise the issue again in a few weeks if he remains AWOL.
18:36<willix>There is also another similar issue when somebody is temporary unable to work due to medical or similar reasons. Then its usually temporary appointment
18:37<shew>(I meant system for a force-replacement. I'm fine with an instant temporary appointment.)
18:37<willix>I agree - move this to mail list. What's is our next item on agenda?
18:38<shew>Oh, one thing we can possibly agree on right now: Is an instant-temporary appointment of a Council member at their own request considered acceptable?
18:38<Julian>I would think so, as long as the temporary assignment was the next candidate in line according to the voting results.
18:38<shew>ie, if I'm going to be out for a month, can I ask Terry to fill in for me and (with Terry's acceptance), that be that?
18:39<Julian>If Terry refuses, you'd also be able to ask Alex.
18:39<Julian>etc.
18:39<shew>Cool.
18:39<Julian>But that's just my opinion.
18:40<shew>sdgathman: Do you agree with that notion as well?
18:40<Julian>Do we want to make a formal rule on that right now? (I'm not against it, just asking.)
18:41<shew>We can wait until next meeting to mull things over.
18:41<shew>I think it would be a good, simple rule, but maybe it's best to allow some thinking-time over a couple weeks.
18:42<SDGathman>Sounds good to me.
18:42<Julian>SDGathman: What, the rule or shew's plan to think it over a couple weeks?
18:42<shew>Cool. (I'm fine with vote now or next-meeting, btw. I'd just prefer next-meeting.)
18:43<SDGathman>The rule.
18:43<Julian>Does anyone explicitly wish to vote on the rule _today_?
18:44<Julian>If so, type "yes" quickly.
18:44<SDGathman>no.
18:45<Julian>Ok, let's delay the issue.
18:45<Julian>4. Coordinating efforts to implement the project agenda
18:46<Julian>Now that we decided on a common agenda for the project <http://new.openspf.org/Project_Agenda>, we should undertake efforts to implement it.
18:47<Julian>I think every council member should shepherd one or more of the agenda items and try to raise enough man power to get it done.
18:47<Julian>...not necessarily do it himself!
18:47<Julian>What do you think?
18:48<Julian>Items could be shared among council members as well...
18:48<Julian>(the responsibility to raise volunteers, that is)
18:48<shew>I'd prefer focusing on item 2 for now: "Review and move content from the old to the new website and try to make the new website sufficiently complete that the old site can be archived"
18:48<willix>I think #2 should be priority for all
18:49<Julian>Agreed. However I think that #3 should be taken care of, too, now.
18:49<willix>WHen we're mostly done with it we can review and move to 3-6 and then 7
18:50<Julian>I think the test suite requires a lot of work, and the set of potential volunteers for #2 is very likely to be mostly disjoint from the set for #3, etc.
18:50<Julian>So we should try to do things in parallel.
18:51<willix>What is envolved in test suite?
18:52<willix>We are talking about certain number of tests for specify types of emails and records and how implimentation reacts?
18:52<Julian>Basically: see what can be salvaged from Wayne's old test suite, update it to match the final spec where necessary, see if it's complete wrt the spec, make a nice package out of it, publish it on the website.
18:53<Julian>Well, as much as possible of the spec should be covered by tests.
18:53<Julian>http://www.schlitt.net/spf/tests/
18:54<SDGathman>Salvaging the test suite is already on my pyspf agenda.
18:54<Julian>BTW, I think project agenda item #4 depends on #3.
18:54<Julian>SDGathman: Very good. Would you want to share the work with other potential volunteers?
18:55<SDGathman>Part of it involves obtaining the DNS data and including it directly in the test suite.
18:55<SDGathman>Much of the test suite resides in DNS servers.
18:55<willix>I still think we should focus on #2 and leave the rest as additional work not necessrily having to be done in parallel to #2
18:55<SDGathman>(Bad)
18:56<SDGathman>I would love to have volunteers. Scott Kitterman is the only one so far.
18:56<Julian>willix: Not necessarily, right. But possibly.
18:56<Julian>(I agree that the test suite should not depend on DNS.)
18:58<Julian>willix: Remember, this is not about doing all the work ourselves, it's about finding volunteers. For that, of course, #2 would take precedence. But as soon as we have enough volunteers for #2 (and #2 may require no more than 1 or 2 more volunteers in addition to Koen and me), we can start seeking volunteers for #3.
18:58<SDGathman>I have an appointment at 15:00u.
18:58<SDGathman>I can delay it some.
18:58<Julian>Huh, it's 19:00 UTC in 2min...
18:58<Julian>You meant 19:00?
18:58<SDGathman>Yes.
18:58<Julian>ok
18:59<willix>Julian, do you have a motion. If not I think we should move on and discuss on mail list as well. But as of right now I probably would not support motion to separate and work on multiple items together.
19:00<Julian>So, who wants to take responsibility for #2? Koen and I already "volunteered" to do some of the work. I can help coordinate stuff, but I'd prefer someone else to write a "please help" message on spf-discuss, etc.
19:00<SDGathman>I volunteered for SPF vs SID.
19:01<Julian>SDGathman: good, thanks!
19:01<willix>Ok. Try to salvage some from old.openspf.org if you can.
19:01<Julian>shew, willix: Could one of you write a "please help with the new website" message and try to raise some volunteers?
19:02<willix>I'll also work on several pages. I wanted to bring in page about history of SPF from my old message and additional draft text I have for 2nd year.
19:02<willix>This weekend I actually have some time!
19:02<willix>I'll write message to spf-discuss.
19:02<Julian>willix: re history of SPF: Very good.
19:02<Julian>willix: Thanks!
19:03<shew>I'm not sure of my time here, with new-job stuff, but I can try to work on the new-site stuff more.
19:03<willix>Do we need message sent to more then just discuss list?
19:03<Julian>SDGathman: Would you be willing to organize the test suite efforts? It would have to be an implementation-independent test suite, though.
19:03<Julian>willix: Send it to spf-webmasters as well.
19:03<willix>ok
19:05<Julian>SDGathman: You might want to use spf-devel for coordination.
19:05<shew>Wiki question: Are the #PRIVATE historical revisions of public pages viewable?
19:05<shew>rather, are they private or public?
19:06<SDGathman>Yes, I'll organize test suite.
19:06<SDGathman>I can break up into tasks.
19:07<Julian>shew: #PRIVATE revisions are private. Non-#PRIVATE revisions are not.
19:08<Julian>(It might be a good idea to always get the private status from the most recent revision in the next release of the wiki software, though. Will have to think about that.)
19:08<Julian>SDGathman: Great!
19:08<Julian>Alright, I think we're done for today. Any other issues?
19:09<shew>SDGathman: Can you make your SPF vs. SID page #Private on the wiki while putting it together, that way others, (like me. :-) ) can try to help as you edit it up.
19:09<Julian>(BTW, I'm not sure the #PRIVATE pragma is case-INsensitive. Better say "#PRIVATE" all the time.)
19:10<shew>Thanks. #PRIVATE then. :-)
19:10<Julian>So, no other issues.
19:11<Julian>Motion: Adjourn.
19:11<SDGathman>shew: ok
19:11<SDGathman>I just typed:
19:11<SDGathman># yum install xmms
19:11<SDGathman>Ooops.
19:12<SDGathman>Had a question on another im
19:14<shew>I have nothing to bring up.
19:14<Julian>Motion: Adjourn.
19:14<willix>seconded
19:14<Julian>Votes?
19:14<willix>what is a time?
19:14<Julian>19:14u: yes
19:14<SDGathman>19:14u yes
19:15<willix>19:14u: yes
19:15<shew>19:14u: yes
19:15<Julian>Meeting is adjourned. Thank you all, and sorry that I underestimated the duration of the meeting!

This report was generated at Sat May 6 23:59:59 UTC 2006.