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/2005/06/05_irc_log.html.

IRC nicknames:
csmChuck Mead
freesideMeng Weng Wong
grumpyWayne Schlitt
JulianJulian Mehnle
MarkKMark Kramer (asarian-host.net)

--- Sat Jun 4 17:24:47 UTC 2005 ---
17:24<Julian>grumpy: I tried to correct the subject of your meeting announcement (s/Wednesday/Sunday/), but then I remembered I can't send mail to moongroup.com.
17:34<Julian>Could you correct that yourself?
17:34<Julian>Also, I finally got a reaction from Andy Newton re the MAAWG conference.
17:38<grumpy>Julian: fixed. thanks
17:39<Julian>grumpy: What is your current schedule for the SPF spec?
17:41<grumpy>I have to leave real soon to see my kids.
17:41<grumpy>I hope to get another revision out tonight.
17:41<grumpy>If I don't, I still plan on getting a final version out to the IETF on Monday.
17:44<Julian>...on Monday, I see.
17:44<grumpy>I'm pretty sure I've mentioned that schedule a couple of times, haven't I?
17:46<grumpy>I gotta go now. I'll be back in 6-8 hrs
17:47<Julian>k
17:48<Julian>Yes, of course you have mentioned the schedule several times. I just wasn't sure it was still current.
--- Sun Jun 5 18:26:07 UTC 2005 ---
18:26<Julian>Meng's calendar for today: http://ical.mac.com/WebObjects/iCal.woa/wa/default?u=mengwong&n=fsConferences.ics&d=5&v=2&m=5&y=2005
18:36<grumpy>So, at 21:00 UTC, Meng has block out time for "Mark"?
18:36<grumpy>Hmmm.
18:36*grumpy sends email to freeside
18:37<Julian>io:~> TZ=EST date -d '21:00 UTC'
18:37<Julian>Sun Jun 5 16:00:00 EST 2005
18:37<grumpy>s/EST/EDT/
18:37<Julian>"Mark" is at 17:00.
18:37<Julian>Oops.
18:37<Julian>io:~> TZ=EDT date -d '21:00 UTC'
18:37<Julian>Sun Jun 5 21:00:00 EDT 2005
18:37*grumpy did a TZ=UTC date -d "17:00 EDT"
18:37<Julian>That can't be right.
18:38<grumpy>what can't be right?
18:38<Julian>Sun Jun 5 21:00:00 EDT 2005
18:38<Julian>EDT != EST + daylight saving
18:38<Julian>EDT is ambiguous
18:38<grumpy>maybe
18:40<Julian>http://www.timeanddate.com/library/abbreviations/timezones/
18:40<Julian>EDT Eastern Daylight Time Australia UTC + 11 hours
18:40<Julian>EDT Eastern Daylight Time North America UTC - 4 hours
18:44<Julian>I always hated these three letter time zone names. With the sole exception of UTC. I really prefer numerical time zones.
20:30<Julian>T = -30min
20:32<grumpy>I didn't get a reply from Meng...
20:32<grumpy>I still hope he shows up.
20:32<grumpy>but I'm not going to recommend waiting for him.
20:32<grumpy>:-<
20:32<grumpy>any minutes for me to read?
20:32<Julian>No, sorry.
20:32<grumpy>ok
20:33<Julian>I am really sorry for not having written the minutes for about the last three meetings...
20:33<Julian>I'm kinda swamped with work these days.
20:34<grumpy>I'll start throwing stones at you after you have gone awol for 2 months like I did.
20:34<grumpy>did you see my announcement of a new -02pre2 draft?
20:36<Julian>No. I'll have to catch up before we start the meeting.
20:37*Julian gets a snack before the meeting starts.
20:51*grumpy returns from putting dinner in the oven
21:01<grumpy>wait(MarkK)]
21:02<Julian>I'm back.
21:02<grumpy>wait(MarkK||freeside)
21:03<Julian>w00t!
21:03<grumpy>hi MarkK!
21:04<MarkK>good evening
21:04<Julian>MarkK: Have you changed ISP?
21:04<MarkK>nope; connectiong from my parents' place tonight
21:05<grumpy>Well, I think we aren't going to wait for Meng.
21:05<MarkK>I think that would be futile, yes
21:05<grumpy>Julian noticed that Meng has blocked out a two hour window of time for "mark" rightnow
21:06<MarkK>what does that mean? MarkL, you mean?
21:06<grumpy>I have no idea
21:06<grumpy>he is in that area
21:06<grumpy>I sent Meng email asking him what's up
21:06<grumpy>no reply so far.
21:06<Julian>http://www.schlitt.net/spf/spf-council/now/irc_log.html#20050605T1826
21:07<MarkK>Quelle surprise
21:08<grumpy>ok, well, we don't have many items to consider on the I-D
21:08<grumpy>so maybe we can get done in a couple of hours.
21:08<grumpy>MarkK: when do you go on vacation?
21:08<grumpy>a week from now?
21:08<grumpy>and when does csm get back?
21:08<grumpy>we *have* to get a quorum soon.
21:09<MarkK>I will be leaving June 12, but am still not sure when the conference is over exactly (around the 20th)
21:09<grumpy>too much stuff is waiting
21:09<Julian>grumpy:
21:09<MarkK>so, lets get started
21:09<Julian>grumpy:
21:09<Julian>* In section 6.2 "exp: Explanation", it is explained that the record must be
21:09<Julian>in US-ASCII due to requirements of RFC2821.
21:10<grumpy>yes
21:10<Julian>Why does RFC 2821 require ASCII for SPF records?
21:10<grumpy>no, just the explanation string
21:10<Julian>Oh, I see.
21:10<Julian>Ok, let's get going.
21:10<grumpy>other parts of the SPF I-D say that the SPF records must be US-ASCII
21:10<grumpy>Ok, first item: What to do about the definition of Pass
21:11<MarkK>I have still not changed my position
21:11<Julian>Well, has anyone had some second thoughts about the issue since last meeting?
21:11<grumpy>2.5.3. Pass
21:11<grumpy>A "Pass" result means that the client is authorized to inject mail
21:11<grumpy>with the given identity. Further policy checks, such as reputation,
21:11<grumpy>or black and/or white listing, can now proceed with confidence in the
21:11<grumpy>identity.
21:12<grumpy>Do we even want to change it?
21:12<Julian>That's the current wording, yes.
21:12<grumpy>Note: I did update Neutral as pre the vote from the last meeting.
21:12<Julian>Well, I would like to change it, but there is no majority in sight for a wording that is closer to mengwong-spf-01, I guess.
21:13<grumpy>Well, I do not want to add "authentic", it opens a can of worms as far as I'm concerned.
21:13<MarkK>'confidence' somehow holds the middle between 'authentic' and 'authorized'. As such, it may not be bad to just keep it as is
21:13<Julian>I would not lobby for "authentic", as this seems to be a taboo.
21:13<MarkK>Because I am still against 'authentic'
21:14<grumpy>I could see adding "legitimate" (but I don't consider "legitimate" to be a synonym for "authentic". related, yeah, but not synonyms)
21:14<Julian>Give me two minutes.
21:14<MarkK>So, maybe we should just keep it as is, and be done with it?
21:14<grumpy>Section 8.10.xx(?) of mengwong-spf-* did say that the sender accepts responsibility, or some such similar words
21:15<grumpy>and I have long said that I consider any argument in the form of "Well, mengwong-spf-* says X, therefore the current spec should also" to be a strong argument.
21:15<MarkK>'legitimate' just means 'legaly within its right'; iot is not at all the same as 'authentic'.
21:15<grumpy>As such, I have have shifted my position somewhat.
21:16<Julian>draft-mengwong-spf-00:
21:16<Julian>When SPF is used to authenticate the return-path, the domain in the
21:16<Julian>source mailbox is now also the party responsible for sending the
21:16<Julian>message.
21:16<Julian>draft-mengwong-spf-01:
21:16<Julian>When SPF is used to authenticate the return-path, the domain in the
21:16<Julian>source mailbox is now also considered accountable for injecting the
21:16<Julian>message into the mailstream.
21:16<grumpy>yes
21:16<grumpy>thanks
21:16<Julian>*think*
21:16*grumpy was just digging for those quotes
21:17<Julian>(Note that draft-mengwong-spf-* even talk of "authenticate".)
21:17<grumpy>yes, mengwong-spf-* uses authentic almost everywhere, while lentczner-spf-* and schlitt-spf-classic-* use authorize
21:17<Julian>Let's stay clear from "authenticate". But what about the words "accountable", "responsible", "legitimate"?
21:17<grumpy>the MARID documents also use authoriz
21:18<Julian>I think at least "accountable" or "responsible" should be mentioned in the "Pass" definition.
21:18<grumpy>I like legitimate the best
21:18<MarkK>only 'legitimate' feels ok with me; the other two smack of legal liabitity too much
21:18*grumpy agrees with MarkK
21:19<Julian>MarkK: Where are you getting this "legal responsibility" thing from all the time? Has any RFC ever had the authority to define legal responsibility???
21:19<grumpy>OTOH, we have to assume that domain owners published records with the mengwong-spf-* understanding of things.
21:19*Julian really wonders.
21:19<MarkK>It would if you define people 'accountable'
21:20<Julian>MarkK: No RFC or other technical standards document can define legal accountability.
21:20<Julian>Only laws can.
21:20<Julian>The IETF is no lawmaking body, in a legal sense.
21:20<MarkK>I just do not think large companies will really adopt something which says they are 'accoutable' for maik sent in that domain; that is just setting themselves up for trouble.
21:21<grumpy>Suggestion: A "Pass" result means that the client is authorized to inject mail with the given identity. Since the domain owner has said that the e-mail is legitimate, further policy checks, such as reputation, or black and/or white listing, can now proceed with confidence in the identity.
21:21<Julian>No.
21:21<grumpy>MarkK: but they already have under the terms of mengwong-spf-*
21:21<Julian>"the e-mail is legitimate" -- We cannot make any assertions about the e-mail as such.
21:22<MarkK>Then I'd sat mengwong-spf-* was wrong. :)
21:22<grumpy>s/e-mail/use of the identity/ ?
21:22<MarkK>Wayne: like I worder earlier
21:22<grumpy>MarkK: got a time machine?
21:22<MarkK>worded
21:22<Julian>MarkK: But people _have_ chosen to publish under the terms of mengwong-spf-*.
21:23<MarkK>Juian: but we also went with draft-schlitt, which uses 'authorized'
21:23<grumpy>yes.
21:23<Julian>MarkK: Nobody asked _me_ about it, obviously. ;-)
21:23<grumpy>although I don't see too many people asking for us to change it back to that.
21:24<Julian>Look, I'm not lobbying for "authentic" anymore. I already said that multiple times now.
21:24<grumpy>and I do remember people, especially me, complaining loudly to meng that authentic was wrong back then.
21:24<MarkK>why not what I proposed? 'can proceed with confidence in the legitimate use of the identity'
21:24<grumpy>MarkK: Give the complete paragraph
21:24*grumpy doesn't want to blotch the editing
21:25<Julian>The problem is, "legitimate" is poorly defined in the context of a technical document.
21:25<grumpy>is it?
21:25<grumpy>"legitimate" is already used several other places in the draft
21:26<MarkK>2.5.3. Pass
21:26<MarkK>A "Pass" result means that the client is authorized to inject mail with the given identity. Further policy checks, such as reputation, or black and/or white listing, can now proceed with confidence in the legitimate use of the identity
21:26*grumpy goes off to do another s/email/e-mail/
21:26<grumpy>I could support Mark's wording.
21:26<Julian>MarkK: Better than the current wording.
21:26<Julian>But let me make a counter proposal.
21:26<grumpy>can we get "better" w/o killing each other?
21:26<grumpy>;-)
21:27*MarkK is listening to counter proposal
21:27<Julian>...
21:29<MarkK>Monday is up soon, though; so I really hope we get it resolved today
21:29<grumpy>yes
21:31<Julian>...
21:31<grumpy>heh
21:31*grumpy was about ready to ping Julian
21:32<grumpy>May 23 10:02:48 <csm-laptop> Guys.... I have my time allotted already for everyday this week... then on Saturday morning I am off on vacation and then the week of the 6th I will be unavailable on Wednesday as I am teaching that week.
21:33<grumpy>Ok, so if we are going to fix the quorum problem, we need to find a time that chuck can meet
21:34<Julian>Ok, this is my proposal:
21:34<Julian>2.5.3. Pass
21:34<Julian>A "Pass" result means that the client is authorized to inject mail
21:34<Julian>with the given identity. The domain can now, in the sense of reputation,
21:34<Julian>be considered responsible for sending the message. Further policy
21:34<Julian>checks, such as reputation, or black and/or white listing, can now
21:34<Julian>proceed with confidence in the identity.
21:34<Julian>--
21:34<MarkK>If we were to have another meeting, next saturday, for instance, I could still attend two meetings
21:34<Julian>(Slight rewording may be appropriate.)
21:35<Julian>(e.g. s/in the sense of/with regard to/)
21:35<grumpy>I slightly prefer MarkK's, but I could see a merger of the two.
21:36<Julian>What elements do you like in each one?
21:36<MarkK>I slightly prefer mine, too :) But at least this one is better
21:36<MarkK>At least this one takes the edges off, legally, I mean
21:37<Julian>Yes. (Even though I don't think it would be necessary.)
21:37<grumpy>I think MarkK only changed the last sentence, while you added a new sentence
21:37<grumpy>I'm suggestion this: ....
21:38<Julian>Perhaps a slightly changed last sentence: "Further policy checks can now confidently be based on the identity."
21:38<MarkK>wayne: yes, I only change a part of your last sentence
21:39<grumpy>A "Pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks, such as reputation, or black and/or white listing, can now proceed with confidence in the legitimate use of the identity.
21:39<Julian>I'd be ok with that.
21:40<MarkK>but you repeat 'reputation' in the second clause too
21:40<Julian>Although we might want to find some wording that removes the duplicate mention of "reputation" (like, removing it in the last sentence).
21:40<grumpy>so did Julian!!!!
21:40<grumpy>but yeah, I could see deleting that part.
21:40<Julian><Julian> Perhaps a slightly changed last sentence: "Further policy checks can now confidently be based on the identity."
21:40<grumpy>...
21:40<Julian>(^^^ that was my previous suggestion wrt the duplicate mention of "reputation")
21:40<MarkK>I still like 'with confidence in' better than 'confidently'; but that is minor
21:41<grumpy>A "Pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity.
21:41<MarkK>yeah :)
21:41<grumpy>oh, s/the domain/the identity/
21:41<Julian>Good.
21:41<MarkK>I like thar
21:41<Julian>grumpy: re s/domain/identity/: Uhm, wait.
21:42<grumpy>yes? no?
21:42*grumpy isn't so sure he likes "identity" as much any more.
21:42<Julian>I can see s///ing it like you said, but I wonder whether SPF actually operates on any other types of identities but domains.
21:43<grumpy>it works with the HELO identity and the MAIL FROM identity
21:43<Julian>Yes there is %{l}, but...
21:44<Julian>grumpy: Do you really think s/domain/identity/ is better?
21:44<grumpy>Well, I guess I slightly like domain better than identity here.
21:44<grumpy>should we make a motion on the 2141u language (unchanged?)
21:44<Julian>Ok, I could live well with Wayne's last proposal.
21:45<MarkK>past it again in full, please
21:45<grumpy>motion: Change the "Pass" definition to: A "Pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity.
21:45<Julian>2145u: seconded
21:45<grumpy>let's wait for MarkK
21:45<Julian>ok
21:46<MarkK>It looks good that way
21:46<grumpy>ok, votes?
21:46<Julian>2145u: seconded
21:46<Julian>2145u: yes
21:46<grumpy>2145u yea
21:46<MarkK>2145u: yes
21:46<grumpy>so ordered
21:46<Julian>Thanks.
21:46<grumpy>ok, next up...
21:46<MarkK>pfew :)
21:46<grumpy>what to do about prefix/sign/qualifier/result/whatever?
21:46<Julian>I'm eager to learn what Frank is going to say about this... ;-)
21:46<grumpy>heh
21:46<grumpy>and everyone else
21:47<Julian>Indeed.
21:47<MarkK>LOL I was thinking the same thing :)
21:47*grumpy waves to Frank
21:47<MarkK>I still like my own idea, 'qualifier'
21:47<grumpy>what to do about prefix/sign/qualifier/result/whatever?
21:47<grumpy>I still don't think any of the suggestions are worth changing things at this late date
21:48<Julian>Well, the "prefix" thing... I really planned to use this low-importance issue as a test case for a community vote, but I simply lacked the time to get the automatic voters register working...
21:48<Julian>I like "qualifier", too.
21:48<MarkK>I posted too, that had no high priority for me, though
21:48<Julian>I agree that "sign" may be too mathematical.
21:49<Julian>"result" is out of the question, since another term in the grammar already uses this name.
21:49<grumpy>I can see the argument for prefix not being the best, but it is used in the text quite a bit and in other documentation.
21:49*grumpy discovers it isn't used that much
21:49<Julian>A lot of "other documentation" is going to become obsolete soon.
21:49<MarkK>also, I like 'qualifier' becauses it desribes what it does: it qualifies a result
21:49<grumpy>qualifies the result, or qualifies the mechanism?
21:50<Julian>The mechanism.
21:50<Julian>Motion: SPF record grammar =~ s/prefix/qualifier/
21:50<grumpy>seconds?
21:51*grumpy hopes for a tie
21:51<Julian>grumpy: Spoil sport.
21:51<grumpy>:-)
21:51<MarkK>I like to second, but cannot find the dar time0index here
21:51<grumpy>that would be 2151u
21:51*grumpy shoots himself in the foot
21:51<Julian>Wait.
21:51<MarkK>2151u: seconded
21:51<Julian>It's 2150u, at least on my side.
21:51<MarkK>ok
21:52<Julian>Nevermind.
21:52<grumpy>oh, yeah, it is 2150u
21:52<grumpy>whatever.
21:52<grumpy>votes?
21:52<MarkK>it is 2151u now :)
21:52<grumpy>2150u no
21:52<Julian>2150u: yes
21:52<MarkK>2151u: yes
21:52<grumpy>so ordered
21:52<Julian>lol
21:52<Julian>Just for the record: 2150u == 2151u
21:53<grumpy>Uh, the last thing I have on my list is "Have I missed anything?"
21:53<Julian>Ok, great.
21:53<Julian>I need to review -02pre2 before I can answer that question.
21:53<Julian>As for today, I don't think there's anything important left.
21:53<MarkK>Gee, in this short a time, we actually decided on a few good things :)
21:53<grumpy>well, one good thing at least. ;-)
21:53<MarkK>:)
21:54<Julian>MarkK: Yeah. We had large amounts of discussion on these issues before.
21:54<grumpy>Ok, if there isn't anything else people can think of on the I-D, the only thing left is the next meeting date
21:54<Julian>Technically, we can't adjourn because we don't have full quorum. ;-)
21:54<grumpy>which I think we have to contact csm/freeside and see what they say
21:54<grumpy>but we *can* schedule another meeting.
21:54<MarkK>re the 'pass' thing, it was bound to happen, as the community, ever since it became much larger, never really opened talked about it
21:55<MarkK>yes, for next wednesday, right
21:55<MarkK>?
21:55<Julian>MarkK: Well, the community is sort of morphing over time anyway, so _if_ the issue would be discussed in a year or so, who might know what would come out of it? ;-)
21:55<grumpy>csm said he couldn't meet Wednesday because he is teaching this week.
21:56<MarkK>and like I said, if we have another next saturday, I can still be present for two meetings before I go
21:56<Julian>We have two options: choose multiple meeting dates today, or wait until Chuck is back and Meng can be reached.
21:56<MarkK>any 2100u will be good this week
21:56<grumpy>I doubt that csm can make it then.
21:57<grumpy>I'm sure he will be tired after just teaching a class and will probably not be able to make it home in time.
21:57<grumpy>So, the other option would be in the morning.
21:57<Julian>Ugh, I think my calendar just screwed up.
21:57<MarkK>I'd like one with csm present, so we have quorum, to decide upon the websie issues
21:57<grumpy>And, if the most critical thing is "how to solve the quorum problem", we might be able to keep the meeting short.
21:58<grumpy>I think we should adjourn until we can set up a time.
21:59<Julian>On Wednesday, anything before 22:00 UTC is bad for me this week.
22:00<grumpy>well, let's adjourn.
22:00<grumpy>night guys.
22:00<grumpy>thanks for showing up.
22:00<Julian>Ok, adjourned.
22:00<grumpy>logs will be posted in an hour (if my scripts are working again)
22:00<MarkK>hey, its the least we can do :) (hint)

This report was generated at Sun Jun 5 23:01:57 UTC 2005.