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/11/25_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 Nov 25 18:59:17 UTC 2006 ---
18:59<Julian>hi MarkK
18:59<MarkK>good evening
19:00<Julian><shew> Julian, do you want to add something into the agenda discussing our reaction to the BITs suggestions/requests?
19:00<Julian>shew: Can you clarify, please? (Excuse if I'm being a bit slow...)
19:04<SDGathman>Hello everyone.
19:05<Julian>hi SDGathman
19:05<MarkK>hello stuart
19:05<Julian>SDGathman: Did you read my mail regarding X-Chat for MacOS X?
19:06<Julian>(I sent it just ~15min ago.)
19:06<SDGathman>No, I'll look now.
19:06<SDGathman>I'm using gaim via tightvnc via a Java application.
19:07<Julian>*cough*
19:08<SDGathman>I can't install anything
19:11<SDGathman>I'm fine with this solution.
19:11<Julian>OK.
19:12<Julian>I just sent our agenda for today.
19:12<Julian>It still has to show up in the spf-council archives... *sigh*
19:12<Julian>Oh, there it is: http://archives.listbox.com/1943/200611/0044.html
19:13<Julian>Any wishes for additions or removals?
19:13<shew>I'm fine.
19:14<MarkK>I'm fine, too
19:14<Julian>SDGathman?
19:14<Julian>Oh, I forgot one thing: 3.5. news items for the upcoming news announcement.
19:16<Julian>SDGathman: Are you there?
19:16<SDGathman>yes
19:16<SDGathman>agenda is fine
19:16<Julian>OK, so let's start.
19:16<Julian>1. Website transition
19:17<Julian>Here's the deal: I'm going to be very busy next week, so I doubt I'll manage to complete the new wizard and "why?" pages by coming Friday.
19:18<Julian>However, Mail::SPF is effectively finished now and I really just need to do those two pages. Therefore I think it would be best if we postponed the website switch for one week.
19:18<Julian>Any comments?
19:19<SDGathman>Can't we switch with old wizard and why?
19:19<MarkK>I see no reason to postpone 1 week extra
19:19<Julian>Well, yes, we could. We would have to link to the relevant parts of the old site, though, and those parts still have links to other parts of the old site.
19:20<MarkK>not to posrtpone, I meant
19:20<shew>I'm fine either way. However, we can always switch before the announcement.
19:20<shew>I'll finally have some time to work on the site myself. (I was unexpectedly busy these last two weeks.)
19:20<Julian>This is not about the announcement (I could live with not mentioning Mail::SPF in it), it's more about the implications of having to link to parts of the old site.
19:21<shew>Then I'm okay with a week's delay.
19:21<Julian>That would be December 8th.
19:22<Julian>(or we could even say Dec 6th or 7th)
19:23<shew>If you're gonig to make a motion on it, i'd suggest the 10th.
19:23<shew>That way we'll have a bit of weekend-time, and cushion.
19:23<Julian>SDGathman, MarkK?
19:24<SDGathman>Disappointed, but if having new wizard is essential for switch, then I guess there has to be a delay.
19:25<SDGathman>Did you say mod_python was available on web server? Should we have a race for the wizard? I'm very busy too, but if the wizard is the holdup ...
19:25<Julian>I don't think that having the _new_ wizard is absolutely essential, but I think it would avoid trouble with the old site, and it would make a better impression on those who actually visit the new site in reaction to the announcement.
19:26<Julian>Well...
19:26<MarkK>yes, better wait until we have the new wizard in place, too
19:26<Julian>Yeah, we could do a race, but any non-Perl solution would probably have a slight disadvantage, because it would somehow have to fit into the site's framework (or at least into the design).
19:26<SDGathman>There are a lot of complaints about braindamage in the old wizard.
19:27<Julian>Yes, I think Alex even stopped handling tickets about the old wizard.
19:27<Julian>:-/
19:28<shew>There is an option of not having a wizard on the site for a week.
19:28<shew>Well, that would require edits on multiple pages, and we'd probably miss some.
19:28<MarkK>that might give us a wave of critique
19:30<Julian>There's one other thing that might justify postponing the news announcement for some days in particular.
19:30<MarkK>which is?
19:31<Julian>I think we need to debate what to do about the next council elections (whether to do any at all, etc.) and include that in the news announcement.
19:32<Julian>Wayne said he wasn't sure whether electing another council next year would make much sense (we could end up with ~10 people electing 5 representatives, or something like that).
19:32<Julian>I don't think he's right, but I think that needs to be discussed properly.
19:33<Julian>Of course postponing the announcement doesn't imply that we'd have to postpone the website switch (but, well, there's a reason for that, too -- see above).
19:33<Julian>What do you think?
19:35<shew>As far as elections, we have no choice in the matter. Any change of election rules should (imho) be voted on by the same people who would vote for the council.
19:35<MarkK>I think wayne may be right; but we could check the 'animo' for it in discuss
19:36<Julian>I think you're both right, and we should at least ask on spf-discuss what people think.
19:36<shew>Julian: Are you suggesting disbanding the council?
19:36<shew>That is, that we shouldn't really have one?
19:36<Julian>shew: No. I think we should make "No other candidates -- Disband the council" as an option like last year.
19:37<Julian>So if less than 5 get elected, then the council would be disbanded.
19:37<shew>Ahh. Okay
19:38<Julian>http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_1fd503d126aaa609
19:38<Julian>Actually, it read "None of those remaining, prefer to hold new elections".
19:39<Julian>Not sure why it didn't read "None of those remaining, prefer to disband the council". Doing another election round usually doesn't make much sense -- people rarely change their mind within a very short amount of time.
19:41<shew>Well, regardless of the website delay or not...election work has to go on.
19:43<Julian>OK, then I'll make this a motion: Postpone the website switch and news announcement. The old and new websites shall be switched around on or before 2006-12-10. The switch shall be publicly announced on the same day the website switch happens.
19:44<shew>19:43u seconded
19:44<Julian>Votes for 19:43u?
19:45<SDGathman>1943u ok
19:45<MarkK>1943u: yes
19:45<Julian>1943u: yes
19:46<shew>1943u: yes
19:46<Julian>OK. I'll do my best to expedite the switch.
19:46<Julian>2. The test suite
19:47<Julian>I think we should release the test suite soon. However we shouldn't release it with a version number of "1.0" or something but use a date-based numbering scheme instead. E.g., "2006.12" or something.
19:47<Julian>That way we can make another release without looking bad.
19:47<SDGathman>Are we going to vote on the ip6/ip4 controversy?
19:47<Julian>Comments on the general idea of releasing the test suite soon and on version numbering?
19:48<Julian>SDGathman: I'm not going to make a motion. But we can vote if someone else does.
19:48<Julian>In any case, I am NOT prepared to debate the "ip6"/IPv4 issue tonight. :-)
19:48<MarkK>yes, I was just gonna ask: what about the ipv4/ipv6 issue (ambiguity) we duscussed last week?
19:49<Julian>I'm just too tired to have any real chances of convincing anyone tonight. :)
19:49<Julian>But if someone wants to make a motion, feel free.
19:49<shew>I like the "2006.11" type scheme.
19:50<MarkK>me too
19:51<Julian>Of course that shouldn't relieve us from trying to get it right the first time. ;-)
19:51<Julian>Actually, I think the test suite is very good and correct already.
19:51<Julian>I just haven't had the time so far to manually review all the "OK"s that the Mail::SPF test driver spits out.
19:52<Julian>And there might still be additions to the test suite later that test more stuff.
19:52<SDGathman>To summarize ip4/6 controversy: shouild ip4 connections on an ip6 interface be considered ip4 only (not match any ip6 mech) or both ip4 and ip6 (match approprate ip6 as well as ip4 mechs)?
19:52<Julian>Good summary.
19:53<SDGathman>I added a simple test for pasting TXT records properly. Will commit tomorrow night. (This meeting is the only work I'm doing from friends house).
19:53<Julian>The difference between both views is that (1) IPv4/IPv6 address spaces are either distinct or IPv6 space is a super set of IPv4 space, and (2) what practical implications are there of doing it one way or the other?
19:54<Julian>But I suggest that we don't debate this right now.
19:54<SDGathman>Ip4 policies are unaffected (that don't have any ip6 mechs).
19:54<shew>I agree with Julian. This isn't appropriate for a council meeting.
19:55<SDGathman>Ok, then should that test be removed for 2006.11 release?
19:55<shew>(I have seen the email controversy, but I haven't followed all the arguments through, and I won't be able to do so during the space of a meeting.)
19:55<MarkK>The longer I think about it, the more I lean towards treating it as just an ipv6 address; regardless of the fact that it is a superset of te ipv4 space, if the address appears in ipv6, it seems reasonable to treat it as ipv6.
19:55<MarkK>but we can discuss it another time :)
19:55<SDGathman>Or at least downgraded to accepting both results?
19:55<Julian>SDGathman: If we really want to release the test suite in 2006-11 (as opposed to 2006-12), then the test should probably be removed or disabled, yeah.
19:55<shew>If that's the only holdup for a 2006.11 release, I would say to remove it for the moment yes.
19:57<SDGathman>MarkK: "just ipv6" is not an option. Possible interpretations of RFC are "ip4 only" or "both ip4 and ipv6" for the ::FFFF:ip4 connections on an ip6 interface.
19:57<Julian>But I would probably defer to the "ip6 never matches IPv4" crowd anyway because I can see the implications it has on existing implementations. It's just one of those things that, if it was changed in a future revision of SPF, would confuse people a lot.
19:57<SDGathman>I will modify test to accept both interpretations for the time being and commit tomorrow night.
19:58<Julian>OK
19:58<Julian>So then we can release rfc4408-tests.yml 2006.11 within the next few days, right?
19:58<SDGathman>What do existing implementations do? Which implementations handle ip6?
19:59<Julian>To be honest, I have no idea.
19:59<Julian>Mail::SPF supports "ip6".
20:00<Julian>BTW, I haven't been able to complete the YAML->XML converter and the RNG schema validator for the test suite yet.
20:00<Julian>But that may not be a priority.
20:00<Julian>(RNG = Relax NG, a simple schema language)
20:01<Julian>http://new.openspf.org/source/project/test-suite/schema.rng?rev=21&view=auto
20:01<Julian>So then we can release rfc4408-tests.yml 2006.11 within the next few days, right?
20:01<SDGathman>Julian: yes
20:02<Julian>OK. Any other thoughts on the issue before we move on?
20:02<SDGathman>Where will it go on web page?
20:02<MarkK>Stuart, yes, you're right: so I guess we'd have to accept both ipv6 and ipv4 then; (hmm, not all that happy with that either);
20:02<SDGathman>MarkK: then you are on Julian's side.
20:03<Julian>SDGathman: I think it should have its own page (I think it already does), which would be linked from the "Implementations" and "Specifications" page (and perhaps other places). Sounds good?
20:03<Julian>http://new.openspf.org/Test_Suite
20:03<MarkK>What does Mail::SPF do in that regard?
20:03<Julian>Currently it considers ::ffff:n.n.n.n both an IPv4 and an IPv6 address.
20:04<Julian>(which can match both "ip4:n.n.n.n" and "ip6:::ffff:n.n.n.n")
20:04<MarkK>Ok
20:05<SDGathman>I would consider matching what most implementations do.
20:05<Julian>Does something need to be decided here right now, or should we move on?
20:06<MarkK>or make it a switch, perhaps?
20:06<MarkK>ok, lets move on
20:06<SDGathman>Move on
20:06<Julian>3. Mail::SPF
20:06<Julian>I added this to the agenda only because it's one of our three current sub-projects. The status is as follows:
20:08<Julian>Mail::SPF itself is 99.5% done (it just needs some documentation fixes and very few other adjustments).
20:08<Julian>I adopted `spfquery` from Mail::SPF::Query and rewrote most of it to work with Mail::SPF instead. That's finished, too.
20:08<MarkK>Personally. I look rather forward to Mail::SPF.
20:09<Julian>I still need to convert `spfd`. That's non-essential.
20:09<Julian>I'm going to make one last pre-release (2.000_003) to CPAN within the next few days and ask for documentation review and some testing on spf-devel and perhaps spf-discuss.
20:10<Julian>Then the final 2.001 release won't be far behind. (2.000 was the initial "release" uploaded by Shevek in 2005, which was in a really, really bad shape).
20:10<Julian>OK, that's it for Mail::SPF right now. If you have any urgent questions, type "..." quickly.
20:11<MarkK>I'll test it, and if there's any issue with it, I'll let you know.
20:12<Julian>(2.000 didn't work right. A lot was missing, and some things weren't designed in a very flexible way. And the entire thing wasn't even dreaming of complying with RFC 4408. It really was an alpha release.)
20:12<Julian>OK, no questions, so let's move on-
20:12<Julian>4. How to react to BITS' desire for some kind of receiver policy?
20:13<Julian>shew asked to discuss this issue briefly, and in a private channel because he wasn't sure what level of privacy was still required by BITS.
20:13<Julian>Shall we go to #spf-private for a few minutes?
20:13<MarkK>ok
20:13<shew>ok
20:36<MarkK>back
20:36<SDGathman>back
20:36<shew>In #spf-private we discussed the need for a BCP-type document for those concerned with receiver policy. I volunteered to edit such a BCP document or white paper, soliciting input from spf-discuss.
20:37<Julian>Awesome! Thanks, shew!
20:37<Julian>I think we can skip the remaining agenda item (5. The RFC errata) and conclude the meeting.
20:37<shew>The BCP/white paper(s) would include recommendations on both publishing records and implementing spf checking.
20:37<Julian>Motion: conclude this meeting.
20:37<shew>20:37: seconded.
20:37<MarkK>2037u: yes
20:37<shew>2037u seconded
20:38<SDGathman>2037u yes
20:38<shew>2037u yes
20:38<Julian>Votes on 2037u?
20:38<Julian>2037u: yes
20:38<Julian>The meeting is concluded. Thanks to everyone!
20:38<Julian>SDGathman: Please extend our apologies to your hosts!
20:38<SDGathman>No problem.
20:39<SDGathman>bye everyone
20:39<Julian>SDGathman: Bye!
20:41<MarkK>Julian, when will you upload MAIL::SPF to CPAN?
20:42<Julian>There's already a 2.000_002 pre-release, but I think it still has some problems, such as a few missing features (but IIRC, it already conforms to the test suite).
20:42<Julian>I'll try to get the 2.000_003 pre-release out tomorrow.
20:42<MarkK>great! Then I can finally get rid of the old one. :)
20:43<Julian>MarkK: --> #spf
20:43<MarkK>yes

This report was generated at Sat Nov 25 23:59:59 UTC 2006.