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/03/28_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

--- Tue Mar 28 15:51:30 UTC 2006 ---
15:51<Julian>grumpy: ping
20:04<Julian>It went roughly like this earlier today:
20:04<Julian>--> {0pm3} (~{0pm3}@schlitt.net) has joined #spf-council
20:04<Julian>--- grumpy gives channel operator status to {0pm3}
20:04<Julian>--- {0pm3} gives voice to Bouncer
20:04<Julian>--- Bouncer gives channel operator status to Julian
20:04<Julian>--- Bouncer gives voice to Julian
20:04<Julian>==
20:05<Julian>I think grumpy has an IRC client that automatically ops others when configured appropriately.
20:05<willix>so was that automated or he did something?
20:05<Julian>I can't be sure, but I think it was automated.
20:06<Julian>Ok, we have quorum, let's start.
20:06<Julian>I sent Mark K. a message asking when he'd be back, BTW.
20:06<Julian>Ok, let's start with change #34.
20:07<Julian>Unfortunately, only John A. Martin replied to my request for additional opinions on spf-discuss.
20:07<Julian>He said: "FWIW IMHO it is less likely to be a mistake to be correct than otherwise. That would rank the variants 3, 2, 1, Original, preferring 3 the most."
20:08<Julian>So, what are your thoughts on #34?
20:08<willix>hehe
20:08<Julian>I still prefer variant 1, and I hate variant 3 (it's too anal retentive IMO).
20:08<willix>I prefer variant #2
20:08<shew>I do not like variant 1.
20:08<shew>Here is my reasoning:
20:09<SDGathman>I agree with the intent of #3 - but am not enough of an ABNF expert to be sure it really does what it says it does.
20:09<willix>I typically prefer most technically correct solution, but in this case it turns out way too ugly
20:09<willix>#2 is really not that bad and fairly easy to read and understand
20:10<shew>If bad syntax should error out with a PERMERROR in general, then I don't like special situations where bad syntax could often (but avoidably) not result in a PERMERROR.
20:10<shew>Which would happen for A:macrostuff.123
20:10<Julian>I could live with #2, however I think the LDH rule comment in #1 actually provides for all the required restrictions.
20:11<shew>Ahh.
20:11<willix>it does and its not unusual to see comment below ABNF that puts restrictions although now IETF prefers to see less of that
20:11<Julian>I mean, implementations don't have to check for "all digits" using their grammar parser. They could check it with a negative regex instead.
20:12<SDGathman>I thought of that last night. It is a lot easier to enumerate non-primes than primes.
20:12<Julian>Like, "foo.111" passes the parser, but then another check =~ /^\d+$/ is performed.
20:12<shew>I don't understand. Would A:macrostuff.123 result in a permerror with #1?
20:13<SDGathman>Why can't we just say that if the TLD is all digitis, then permerror.
20:13<Julian>shew: Yes, I think so.
20:13<Julian>The LDH rule says so.
20:13<SDGathman>Checking full spec to see if it is clear that the LDH rule should be applied...
20:14<Julian>Let me quote from RFC 3696: (attention, pasting!)
20:14<Julian>Any characters, or combination of bits (as octets), are permitted in
20:14<Julian>DNS names. However, there is a preferred form that is required by
20:14<Julian>most applications. This preferred form has been the only one
20:14<Julian>permitted in the names of top-level domains, or TLDs. In general, it
20:14<Julian>is also the only form permitted in most second-level names registered
20:14<Julian>in TLDs, although some names that are normally not seen by users obey
20:14<Julian>other rules. It derives from the original ARPANET rules for the
20:14<Julian>naming of hosts (i.e., the "hostname" rule) and is perhaps better
20:14<Julian>described as the "LDH rule", after the characters that it permits.
20:14<Julian>The LDH rule, as updated, provides that the labels (words or strings
20:14<Julian>separated by periods) that make up a domain name must consist of only
20:14<Julian>the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen.
20:14<Julian>No other symbols or punctuation characters are permitted, nor is
20:14<Julian>blank space. If the hyphen is used, it is not permitted to appear at
20:14<Julian>either the beginning or end of a label. There is an additional rule
20:14<Julian>that essentially requires that top-level domain names not be all-
20:14<Julian>numeric.
20:14<Julian>--
20:15<willix>that is 100% what #3 says :)
20:15<Julian>I know.
20:15<Julian>Yet, we needn't codify the LDH rule if RFC 3696 doesn't do it.
20:16<SDGathman>I would not have guessed from #1 that the comment allowed me to permerror on all numeric TLDs.
20:16<SDGathman>At least, not from the grammar alone.
20:16<Julian>We could clarify the "LDH rule" comment.
20:16<shew>I still do not see it.
20:17<Julian>See what?
20:17<willix>that is one of the reasons I think we should go with #2, only some are going to be particular enough to read LDH rule
20:17<shew>Oh, I see it. Last sentence. :-)
20:17<shew>"There is an additional rule that essentially requires that top-level domain names not be all-numeric."
20:18<Julian>There won't be "tons" of SPF implementations anyway. There will be a very limited number which can be fixed easily if problems are found.
20:19<shew>So basically that means that variant #1 is technically equivalent to variant #3.
20:19<shew>Does everyone think the same?
20:19<Julian>I think so, it's just not 100% codified in the grammar.
20:21<SDGathman>Is it a convention that references to RFCs in a grammar mean you should use that other RFCs ABNF at that point?
20:21<willix>not really, because many RFCs actually do not have quite correct grammer
20:22<willix>It is ok to fix if you know something is wrong basically
20:22<Julian>I have an idea.
20:23<SDGathman>Can we add a paragraph that says to throw PermError when TLD doesn't match LDH rule?
20:23<shew>Oh, the Name thing (#35) is both in Appendix A and 4.6.1.
20:23<Julian>Idea: Use variant 1, then say "See LDH rule and additional restrictions in [RFC3696], Section 2".
20:23<Julian>...in the comment.
20:23<shew>That is a good idea.
20:24<willix>that is fine but I still don't think people are going to read it
20:24<shew>Can I ask about #35 for a second?
20:24<SDGathman>How do they know they are supposed to throw a Permerror?
20:24<Julian>The "toplabel" part of the grammar is also listed in the body of 8.1., "Macro Definitions".
20:25<willix>if we really want to say something about it, we need sentence or paragraph in actual draft text and not just small reference in abnf
20:25<shew>This is embarassing, but I am confused now about where "name" is used other than defining unknown modifiers. (!)
20:26<Julian>From the SPF spec:
20:26<Julian>4.6. Record Evaluation
20:26<Julian>...
20:26<Julian>Implementations MAY choose to parse the entire record first and return "PermError" if the record is not syntactically well formed. However, in all cases, any syntax errors anywhere in the record MUST be detected.
20:26<Julian>--
20:26<willix>yes good notice. make sure its changed in both places
20:28<willix>where is that paragraph from?
20:28<Julian>The "name" grammar element is also used in the definition of the "key" element (part of the "header" -- now "header-field" -- element).
20:28<Julian>willix: It's from "4.6. Record Evaluation", as I pasted.
20:28<shew>The reason I bring up #35 out-of-order, as it were, is that I kept thinking that it was related to the toplabel issue, but toplabel is used recursively, without refering to "name". If "name" is really only used in defining the allowed construction of unknown modifiers, then...that makes discussion of #34 *completely* unrelated to #35.
20:29<willix>How about we change 4.6 first paragraph to note about invalid TLD
20:29<SDGathman>I would like that.
20:29<willix>let me work on it for a sec
20:29<shew>Wait..more than a few, but nothing related to domain names..
20:30<shew>"Name" is used for unknown-modifier, key, and identity, and that's all.
20:30<shew>Okay, my confusion is apparantly over on that.
20:30<Julian>No, we shouldn't change 4.6 to note about invalid TLDs. This is way too specific for section 4.6.
20:31<Julian>If we noted about invalid TLDs there, we'd have to note about ~500 other things there, too.
20:31<willix>Well, my view is that we either note about it in text or we try to deal with it in abnf
20:31<SDGathman>Could note in 8.1 - would get seen there but is off-topic.
20:32<SDGathman>I like refering to an RFC better that trying to recreate the exact same effect ourselves. That makes the intent clear.
20:32<Julian>"we either note about it in text or we try to deal with it in abnf" -- Only if we complete the grammar definition for "ip6-network" first, which is currently defined as follows:
20:32<Julian>ip6-network = <as per [RFC 3513], section 2.2>
20:32<Julian>; e.g., 2001:DB8::CD30
20:33<Julian>...and you _don't_ want to have a complete grammar for that in the spec, believe me.
20:33<willix>that is ok
20:33<SDGathman>The only thing not clear is that failure to match the LDH rule is a syntax error. If that was clear in the ABNF, then the note about permerror for syntax errors is quite clear.
20:33<shew>Hmm.
20:33<willix>we 100% defer to another RFC
20:33<shew>So it's sounding like variant 1 makes the most sense.
20:33<shew>(Ignoring the trailing "." for the moment.)
20:34<shew>Is that the consensus now?
20:34<shew>Most-open-in-abnf, restrictions-via-reference.
20:35<willix>I'll not vote for #1, I'll most likely abstain on that option
20:35<shew>What is your current objection to #1?
20:35<Julian>If you want to see the grammar of IPv6 addresses, look here: http://www.mehnle.net/source/odds+ends/vim/syntax/bindzone.vim?view=auto
20:35<Julian>It's not pretty.
20:35<SDGathman>Yes, as long as its clear that toplable needs to conform to LDH rule, and the given grammar is a simplification for exposition only.
20:37<shew>Ooh.
20:37<shew>Problem:
20:37<willix>that was one fun set of regex :)
20:37<shew>What about A:macro-stuff._spf.example.com ?
20:37<Julian>shew: What about it?
20:38<SDGathman>The macros can create invalid names. That is not a syntax error.
20:38<shew>That would seem to require permerror by LDH rule because of _spf, which isn't [ alphanum / "-" ]
20:38<Julian>SDGathman: We can't catch semantical errors with the grammar.
20:39<SDGathman>That is what I was saying.
20:39<willix>_spf is not toplabel
20:39<shew>so _spf is considered a macro-literal then?
20:40<willix>I think so. What do others think?
20:40<willix>BTW - are we talking about #34 or #35?
20:40<Julian>Doesn't the LDH rule _generally_ apply to TLDs only? That's why RFC 3696 says:
20:40<Julian>"Any characters, or combination of bits (as octets), are permitted in DNS names. However, there is a preferred form that is required by most applications. This preferred form has been the only one permitted in the names of top-level domains, or TLDs. In general, it is also the only form permitted in most second-level names registered in TLDs, although some names that are normally not seen by users obey other rules."
20:41<shew>If "_spf" is considered a macro-literal, that would mean that macro-literals can include a ".", which would mean that any "toplabel" restrictions are superfluous except for the tld.
20:41<Julian>Definitely. That's why it's called "toplabel".
20:41<shew>We're talking only about #34. #35 has nothing to do with domain names.
20:41<SDGathman>Can't the comment say:
20:41<SDGathman>; must also conform to LDH rule as per [RFC 3696]
20:41<Julian>Sure, although it might be good to mention the "additional restrictions", too.
20:42<shew>Let me rephrase.
20:42<Julian>s/also//
20:42<willix>if you refer to another RFC from ABNF you generally do it by directly deferring specification of the rule to that RFC
20:43<shew>As I see it, we have something that has: macro.one.two.three.four.five.com, where "one.two.three" is a macro-literal, and "four.five.com" is a toplabel, but with the decision of where macro-literal ends and top-label begins as being completely arbitrary.
20:43<SDGathman>how about:
20:43<SDGathman>toplabel = < as per LDH rule in [RFC 3969]>
20:43<Julian>shew: No, toplabel must not contain embedded dots.
20:44<Julian>SDGathman: I think that would be acceptable.
20:44<shew>Oops. rewording:
20:44<Julian>toplabel covers everything after the last dot (modulo the trailing dot).
20:44<willix>toplabel = < as per LDH rule in [RFC 3969]> is ok by me, but I would still prefer to specify if we can
20:45<shew>Reworded:
20:45<shew>As I see it, we have something that has: macro.one.two.three.four.five.com, where "one.two.three" is a macro-literal, and "four.five.com" is a domain-end, but with the decision of where macro-literal ends and domain-end begins as being completely arbitrary.
20:45<Julian>willix: We can. But then we'd have to specify ip6-network, too. Both are ugly.
20:45<willix>it would make more sense to write < as per ..> if the rule was complex and required other rules but if we can do it with one line...
20:46<Julian>willix: "if we can do it with one line" -- Please propose a one-liner for toplabel.
20:46<willix>I did - #2 is pretty damn close
20:46<willix>you can change #3 to be one-line too, but it would be long
20:47<Julian>But not close enough. If we choose #2, we still have to rely on the implementor checking RFC 3696 anyway, so what's the point?
20:47<SDGathman>If we try to copy the LDH rule, at least the comment make the intent clear to implementors if we make a mistake.
20:47<shew>To me it looks like that could be put in the "toplabel" (or of course "name") grammar to make A:macro.111.com permerror.
20:48<willix>I don't see it as possibility that anybody would care that the rule does not allow for "1-1" as tld
20:48<SDGathman>So apart from completely deferring, we should go with #3.
20:48<shew>Rather: To me it looks like that *nothing* could be put in the "toplabel" (or of course "name") grammar to make A:macro.111.com permerror.
20:48<SDGathman>Or we could pretend that not allowing for "1-1" was a mistake...
20:48<Julian>shew: To your earlier question: The question is, is "foo.bar" a valid macro-expand?
20:49<shew>It's a valid macro-string.
20:49<SDGathman>Yes, we are only catching all-numeric TLD because it catches the common error
20:49<SDGathman>of A:1.2.3.4
20:49<shew>"foo.bar" is a valid macro-string, not a valid macro-expand.
20:49<Julian>shew: But a macro-string can't be part of domain-end.
20:51<Julian>So "foo.bar" can't be a valid domain-end, so there's really no ambiguity.
20:52<SDGathman>We could include an example of throwing permerror on invalid TLD.
20:52<Julian>domain-end is only supposed to be either ".<toplabel>" or "%{X}" (which in turn could expand to _anything_).
20:52<shew>Right, but it's completely ambiguous where macro-string stops and domain-end begins. That means that we have nothing to prevent "a:111.com" from being considered valid syntax.
20:53<Julian>How is it ambiguous?
20:53<Julian>Let me test "111.com" against the grammar...
20:53<Julian>domain-end can't contain dots, so at most "com" could be a domain-end.
20:53<Julian>".com", that is.
20:54<Julian>Oh, now you tricked me!
20:54<Julian>Why should "a:111.com" be a PermError in the first place??
20:54<Julian>I don't think it should.
20:55<Julian>We simply cannot codify all the different TLD registries' second-level-domain restrictions in the grammar, nor should we.
20:55<willix>111.com is valid domain
20:55<Julian>Exactly.
20:55<shew>Okay. "111.com" can't be a FQDN, but "111" can me a macro-string.
20:55<Julian>Why can't 111.com be a FQDN??
20:55<shew>Okay, then take "A:_spf.com"
20:56<shew>That won't permerror either.
20:56<Julian>...because it's absolutely valid.
20:56<shew>Do we have it as a goal that it should permerror?
20:56<SDGathman>Nor should it.
20:56<SDGathman>Only all numeric TLDs should permerror. This meeting is to decide how best to express that in the ABNF.
20:56<Julian>You can't register the second-level domain "_spf" at the .com registry, but that doesn't make it an invalid FQDN from DNS' point of view.
20:57<shew>So "A:(((.com" shouldn't permerror either then.
20:57<SDGathman>Correct.
20:57<Julian>Right.
20:57<Julian>"(((" is a valid DNS label.
20:57<willix>correct, its not valid FQDN but it is valid DNS name
20:57<shew>Okay, then give me a moment to ponder.
20:58<Julian>I'll tell you what, this is part of one of my zone files (UTF-8-enabled IRC client required for proper display of the last line):
20:58<Julian>Any characters, or combination of bits (as octets), are permitted in DNS names. However, there is a preferred form that is required by most applications. This preferred form has been the only one permitted in the names of top-level domains, or TLDs. In general, it is also the only form permitted in most second-level names registered in TLDs, although some names that are normally not seen by users obey other rules.
20:58<willix>FQDN definition is not our problem, that is registrar deligation problem
20:58<Julian>Uhh... strike my last statement.
20:59<shew>So this means that the only thing we're concerned with with #34 is disallowing "bad" TLDs.
20:59<SDGathman>Right, and not disallowing any possible future TLDs.
20:59<shew>And we're *not* concerned with anything to the left of the TLDs.
20:59<SDGathman>Correct.
20:59<shew>Understood.
21:00<Julian>I'll tell you what, this is part of one of my zone files (UTF-8-enabled IRC client required for proper display of the last line):
21:00<Julian>konnichiha IN CNAME io.mehnle.net.
21:00<Julian>xn--28j2a3ar1p IN CNAME io.mehnle.net.
21:00<Julian>IN CNAME io.mehnle.net.
21:00<Julian>--
21:00<willix>show: correct, TLD is the only thing codified because in part so they are not confused with ip addresses
21:00<willix>btw - my launch hour is ending
21:00<Julian>(The latter is a perfectly valid FQDN.)
21:01<Julian>Ok, so can we agree on this:
21:02<Julian>toplabel = <as per LDH rule and additional TLD restrictions in [RFC 3969], Section 2>
21:02<Julian>?
21:02<SDGathman>yes
21:02<shew>So the web page is incorrect in: "The current spec is too restritive and prohibits the use of domain names that start or end with number", in that the current spec does *not* prohibit domain names that begin with a number.
21:02<Julian>shew? willix?
21:03<shew>That sounds good.
21:03<Julian>I think that comment should be subject to s/domain name/top-level domain name/.
21:03<willix>I'm probably ok with it. Still prefer direct definition though
21:04<Julian>Ok, let's vote on change #25 as modified above.
21:04<shew>Wait..Does that address the trailing-dot?
21:04<Julian>Not yet.
21:04<Julian>Good point.
21:05<Julian>OLD:
21:05<Julian>domain-end = ( "." toplabel ) / macro-expand
21:05<Julian>NEW:
21:05<SDGathman>Maybe new label:
21:05<SDGathman>tld = < as per ... >
21:05<SDGathman>toplabel = tld [ "." ]
21:05<Julian>domain-end = ( "." toplabel [ "." ] ) / macro-expand
21:05<Julian>We don't want to have _both_ "tld" and "toplabel". That's confusing.
21:05<willix>don't bother - just add "." as part of domain-end ABNF
21:06<willix>i.e. domain-end = ( "." tld [ "." ] ) / macro-expand
21:06<Julian>That's what I said.
21:06<SDGathman>My concern about optional dot is that is shouldn't be published.
21:06<Julian>Probably true.
21:06<SDGathman>Publishing a trailing dot runs the risk of a permerror.
21:06<Julian>Let me see.
21:06<SDGathman>From old implementations.
21:07<shew>Grr. This whole time I was reading as if it was "domain-end = 1* ( "." toplabel ) / macro-expand"
21:07<Julian>We would need to add a sentence to section 8.1, where domain-end is first defined.
21:07<Julian>shew: :-)
21:08<Julian>Oops, from 8.1:
21:08<Julian>By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, and so the list of parts may contain empty strings. Macros may specify delimiter characters that are used instead of ".".
21:08<Julian>--
21:09<shew>Okay, even if there were no added trailing dot on the domain-end definition, does the reference to RFC 3969 imply one anyway?
21:09<Julian>So we'd have to insert that new sentence _above_ this paragraph and have it say that trailing dots should be removed before continuing processing.
21:10<willix>reference does not imply it
21:10<Julian>From RFC 3696: The DNS specification also permits a trailing period to be used to denote the root, e.g., "a.b.c" and "a.b.c." are equivalent, but the latter is more explicit and is required to be accepted by applications.
21:11<willix>ok, sorry
21:11<willix>have not read it fully - new rfc
21:11<Julian>But that doesn't mean the dot is part of the TLD, which it isn't.
21:12<shew>But a "required to be accepted by applications".. To me that sounds as if there will be confusion on this issue unless it's addressed somehow.
21:12<shew>continued confusion even.
21:12<Julian>It's called "toplabel", implying that it is a _label_, not an entire top-level domain, possibly with a trailing dot. Labels don't have trailing dots.
21:12<shew>(And not just me.) :-)
21:13<Julian>That's why I suggested to add the optional trailing dot to the "domain-end" definition, not to the (now implicit) "toplabel" definition.
21:14<Julian>Again -- SPF section 8.1 says: By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, and so the list of parts may contain empty strings. Macros may specify delimiter characters that are used instead of ".".
21:14<Julian>I think the "no special treatment is given to leading, trailing, or consecutive delimiters" part could be problematic.
21:14<Julian>Why was it inserted in the first place? (Yeah, I doubt anyone remembers why.)
21:15<Julian>Anyway, that part implies that there _may_ be trailing dots. So we could just insert another sentence above that paragraph, saying that trailing dots must be accepted but should not be published without very good reasons.
21:16<SDGathman>Julian, I like that.
21:16<willix>Lets just add what you just said
21:16<shew>Delimiters can't appear outside of macro-string though, right?
21:17<Julian>I'll try to rephrase the paragraph, just a moment.
21:17<shew>Because if that's true, then that paragraph is not important as far as trailing dots to the tld.
21:18<Julian>shew: Dots _can_ appear outside macro-strings, even in the current "domain-end" definition:
21:18<shew>Looking into that to see if that guess is true..
21:18<Julian>domain-spec = macro-string domain-end
21:18<Julian>domain-end = ( "." toplabel ) / macro-expand
21:18<Julian>--
21:18<Julian>So at least one dot can appear outside macro-string.
21:18<Julian>If we allow an additional trailing dot, that makes two.
21:19<Julian>Also, macro-expand may expand to something with dots.
21:19<shew>Right,
21:19<Julian>(the macro-expand in domain-end I mean)
21:19<shew>but there's never a "delimeter" after domain-end.
21:19<shew>delimiter
21:19<Julian>True. So?
21:20<shew>So the ignore-extra-delimiter bit you quote isn't relevant to whether trailing "."'s are allowed after TLDs.
21:20<SDGathman>We can add optional trailing dot to domain-end, then advise against it in 8.1.
21:21<SDGathman>Making explicit the "liberal in what you accept, strict in what you send" principle.
21:22<shew>Why advise against it?
21:22<shew>If it's added to domain-end?
21:22<SDGathman>Advise against publishing it.
21:22<SDGathman>Because of existing implementations.
21:22<shew>Okay.
21:23<SDGathman>Or just warn that older implementations may not accept it.
21:23<SDGathman>We don't want a mass withdrawal of SPF records because of PermErrors from trailing dots.
21:24<shew>We could also add a comment to domain-end saying that trailing "." are not allowed.
21:24<Julian>Ok, here's my proposal for the 8.1 paragraph:
21:24<Julian>By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, and so the list of parts may contain empty strings. (Older versions of SPF prohibited trailing dots in domain names, so those should not be published by domain owners, although they SHOULD be accepted by implementations conforming to this document.) Macros may specify delimiter characters that are us
21:24<Julian>ed instead of ".".
21:24<Julian>--
21:24<SDGathman>Accepting trailing dot could be a feature when used with macro expansion.
21:24<shew>(It took me a while to think through Julian's comment on labels and 3696.
21:25<Julian>All I did was adding the "(...)" sentence that's in parentheses.
21:25<SDGathman>We haven't discussed expansion resulting in trailing dot.
21:26<Julian>I think my proposal covers that.
21:26<SDGathman>Yes.
21:26<Julian>(...by analogy, if not explicitly.)
21:27<Julian>Perhaps we should remove the parentheses I added, or the RFC Editor might have a problem with the "SHOULD" within parentheses.
21:27<SDGathman>But the syntax needs to allow trailing dot also - or an explicit one will trigger Permerror.
21:27<shew>SDGathman: I don't agree with the "liberal in what you accept, strict in what you send" principle here.
21:27<Julian>The above 8.1 paragraph rewording goes hand in hand with the following grammar change (mentioned above several times):
21:28<Julian>domain-end = ( "." toplabel [ "." ] ) / macro-expand
21:28<Julian>--
21:28<SDGathman>Shew, I'm fine with that too. We could brush off the complaints about consistency with other RFCs and simply make an explicit prohibition of trailing dot.
21:28<Julian>So, can we finally vote on that?
21:28<SDGathman>It doesn't server any useful purpose.
21:28<Julian>_What_ doesn't?
21:28<shew>I think the first question to ask is whether we want to allow trailing dots in domain names or not.
21:29<shew>We're sort of arguing different sub-sections of that.
21:29<Julian>I think there was rough(!) community consensus that trailing dots should be allowed...
21:29<SDGathman>I would prefer not allowing trailing dots.
21:29<shew>Classicaly we've said no. We could change that as it's a somewhat minor change.
21:30<SDGathman>But I can accept them if consistency with other RFCs makes more people happy.
21:30<SDGathman>I certainly won't use them.
21:30<Julian>I won't use them either but I think they should be accepted.
21:30<shew>I didn't sense community consensus either way, but mostly because there wasn't a huge amount of discussion.
21:30<Julian>There's really no harm in new implementations accepting them.
21:30<shew>I'm trying to think of a good reason to allow them.
21:30<Julian>Who, except for Frank, was against it?
21:30<shew>I've come up with a half of a reason to allow them.
21:31<shew>Namely: If a future version of SPF was done via positional modifiers, then there could be additional meaning assigned to domain names ending with a dot versus not ending with a dot.
21:31<Julian>Interesting.
21:31<shew>allowing trailing dots would allow for that flexability, whereas disallowing would cut it off completely.
21:32<SDGathman>Shew, yes - some sort of environment that allows relative names.
21:32<Julian>...though too esoteric right now.
21:32<shew>I haven't figured out exactly how that would actually be useful, but..I can personally take it as a good enough reason not to cut off relative domains used in future semi-expansions of SPF via positional currently-unknown modifiers.
21:32<Julian>Look, v=spf2.1 can use an entirely different grammar. It can even work like this: "... 1.2fps=v".
21:33<Julian>Let's not discuss future extensions.
21:33<shew>Julian: I refer to the addition of functionality via scoped modifiers but "v=spf1" strings, done in a backwards-compatible way.
21:33<Julian>Positional modifiers don't exist in v=spf1.
21:34<Julian>We're not making progress.
21:34<shew>Technically no, but unknown modifiers do, and later-defined modifiers could be defined to be positional.
21:34<shew>The point is, that's a possible reason why allowing trailing dots could be barely useful at some future date.
21:34<SDGathman>A modifier could accept both absolute and relative names if trailing dot was allowed.
21:34<SDGathman>However, I would still prefer to leave it alone.
21:35<Julian>*sigh* Trailing dots can occur even with the current RFC wording, because %{X} can in theory expand to "....foo..bar..zip...!.."
21:35<SDGathman>Yes, I pointed that out earlier.
21:35<SDGathman>Macro expands can already result in trailing dot.
21:35<SDGathman>We should certainly accept them in that case.
21:36<shew>If that's true then there's no argument.
21:36<SDGathman>The issue is whether to throw PermError when a literal trailing dot is present.
21:36<Julian>So the rewording of that 8.1 paragraph I proposed earlier would be useful in any case, and what would be the harm of allowing trailing dots in domain-end (not just macro-string), too?
21:36<shew>But I don't see it. I thought you had to say "A:${X}.something", not just "A:${X}"
21:37<Julian>You can very well say "a:${X}"
21:37<shew>Julian: How does that conform to: "domain-spec = macro-string domain-end"?
21:37<shew>oh.
21:37<shew>hmm.
21:37<Julian>macro-string can be empty.
21:38<Julian>"${X}" is a valid macro-expand.
21:38<Julian>We're going in circles now.
21:38<shew>Oh crap.
21:38<Julian>s/${X}/%{X}/ of course...
21:38<shew>I just realized something.
21:39<shew>Let's so macro-string is empty.
21:39<shew>SO you just have domain-end
21:39<Julian>So?
21:39<shew>and domain-end can be "( "." toplabel ) / macro-expand"
21:39<shew>but it's just a macro-expand,
21:40<Julian>I don't think we should rehash all of the grammar now. I am convinced it is correct.
21:40<shew>You could just say %_
21:40<shew>or A:%_
21:40<Julian>(as correct as it can be)
21:41<shew>or A:%
21:41<shew>oops A:%
21:41<SDGathman>I don't think a macro expansion can result in a trailing dot.
21:41<Julian>Yes, that's allowed by the grammar.
21:41<Julian>shew: You're fighting X-Chat with % % ;-)
21:41<shew>You're right. :-)
21:41<shew>A:%%
21:41<shew>there.
21:41<shew>:-)
21:43<SDGathman>I guess macro-literal could do it.
21:43<SDGathman>OK, so we need to allow trailing dot after macro expansion.
21:43<Julian>No, to what end??
21:43<SDGathman>Do we want to allow explicit trailing dot?
21:43<shew>Apparantly it's already allowed via macro-literal.
21:44<Julian>What problem are we trying to solve right now?
21:44<shew>Damn. No it isn't.
21:44<SDGathman>A complaint from someone that not allowing trailing dot was inconsitent with other RFCs.
21:44<Julian>Agreed.
21:45<shew>You can't get to a trailing dot via macro-literal.
21:45<Julian>Why not?
21:45<Julian>macro-literal = %x21-24 / %x26-7E
21:45<Julian>; visible characters except "%"
21:45<Julian>That includes %x2e, which is a dot.
21:46<shew>Okay: "You can't get to a trailing dot via micro-literal starting from domain-spec."
21:46<SDGathman>Accepting trailing dot is relatively harmless - unless we screw up the ABNF in the process.
21:47<Julian>shew: But a domain-spec _always_ ends in a domain-end, which allows trailing dots, doesn't it?
21:47<SDGathman>Publishing trailing dot is problematic.
21:47<Julian>(if modified as above)
21:47<Julian>SDGathman: Yes, it is.
21:48<shew>Julian: You are right.
21:48<Julian>We could also say:
21:48<Julian>domain-end = ( "." toplabel ) / macro-expand [ "." ]
21:48<Julian>...instead of:
21:49<Julian>domain-end = ( "." toplabel [ "." ] ) / macro-expand
21:49<shew>So basically we have a situation where a trailing-dot can be generate via a macro-expansion, but not via a macro-literal (as you can't get there from there), nor via a domain-end nor toplabel.
21:49<Julian>...but I don't see the point.
21:49<Julian>Eh?
21:49<shew>oops
21:49<shew>drop the domain-end part.
21:50<Julian>Trailind dots should _by_definition_ only be generatable by domain-end!
21:51<shew>Rewording: So basically we have a situation where a trailing-dot can be generated via a macro-expansion, but not via a macro-literal (as you can't get there from there) nor toplabel.
21:52<Julian>What situation do you mean? With the _current_ RFC text, or with my proposed grammar change?
21:52<shew>Current.
21:52<Julian>Then I agree.
21:53<Julian>So?
21:54<shew>So it's inconsistent if "A:%{X}" allows for a valid, non-PERMERROR expansion to "A:example.com.", but a direct "A:example.com." would cause a PERMERROR.
21:54<Julian>True, sort of.
21:54<shew>Well, the first causes a permerror, and the second doesn't. Whether that's considered inconsistent is a judgement call.
21:55<shew>SDGathman, does that current state of things bother you?
21:55<Julian>Why does the first cause a PermError?
21:55<Julian>What "first" do you mean?
21:55<shew>backwarsd.
21:55<shew>I said it backwards.
21:55<Julian>Agreed.
21:55<shew>The second can cause a permerror, ("A:example.com."), but not the first.
21:56<SDGathman>The current state of the RFC wrt trailing dot does not bother me. I am willing to make the change to accomodate people who it does bother.
21:56<Julian>*sigh* Again:
21:56<Julian>Ok, here's my proposal for the 8.1 paragraph:
21:56<Julian>By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, and so the list of parts may contain empty strings. (Older versions of SPF prohibited trailing dots in domain names, so those should not be published by domain owners, although they SHOULD be accepted by implementations conforming to this document.) Macros may specify delimiter characters that are us
21:56<Julian>ed instead of ".".
21:56<Julian>--
21:56<Julian>This paragraph rewording goes hand in hand with the following grammar change (mentioned above several times):
21:56<Julian>domain-end = ( "." toplabel [ "." ] ) / macro-expand
21:56<Julian>--
21:56<Julian>What's the issue with that?
21:57<SDGathman>I am fine with that.
21:57<SDGathman>It should hopefully make a few more people happy, and the rest of us don't have to put in the dots.
21:58<shew>What does that do to "A:example.com..." ?
21:58<SDGathman>Permerror.
21:58<shew>The dots aren't delimiters there.
21:58<Julian>(BTW, I think we should s/SHOULD/should/.)
21:58<SDGathman>Only only trailing dot is allowed.
21:58<shew>Okay.
21:58<SDGathman>How about A:example.com%2e%2e%2e
21:59<Julian>SPF doesn't perform URL-decoding.
21:59<Julian>macro-literal = %x21-24 / %x26-7E
21:59<Julian>; visible characters except "%"
21:59<Julian>So that's a PermError.
21:59<SDGathman>How about A:example.com%x2e%x2e%x2e
21:59<shew>So "A:${X}." would also permerror.
21:59<Julian>shew: Yes.
21:59<shew>Well, "A:example.com%x2e%x2e%x2e.com" would not permerror.
21:59<Julian>If %{X} needs a trailing dot, it should expand with one.
22:00<Julian>shew: Yes, it would.
22:00<shew>A the example.com%x2e%x2e%x2e would be a macro-literal.
22:00<Julian>macro-literal cannot contain "%".
22:00<shew>OH yes.
22:00<shew>Okay.
22:01<Julian>macro-string can contain "%", but only as part of macro-expand, which doesn't allow "2e" to follow "%".
22:01<shew>So "A:example._____.com" would not permerror.
22:02<shew>This is making more sense now.
22:02<Julian>No, and rightly so.
22:02<shew>I like your wording.
22:02<Julian>It has minor issues.
22:02<Julian>Let me make a minor revision.
22:03<Julian>By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, and so the list of parts may contain empty strings. (Older implementations of SPF prohibit trailing dots in domain names, so those should not be published by domain owners, although they must be accepted by implementations conforming to this document.) Macros may specify delimiter characters that are
22:03<Julian>used instead of ".".
22:03<Julian>--
22:04<Julian>I essentially made these changes: s/Older versions of SPF/Older implementations of SPF/, s/SHOULD/must/ (because the grammar mandates that it is valid)
22:05<shew>Okay.
22:05<shew>I'm okay with that.
22:05<Julian>English grammar question: Does "those" refer to "Older implementations of SPF" or to "trailing dots"?
22:06<SDGathman>refers to nearest possible term.
22:06<SDGathman>So would be trailing dots.
22:06<Julian>Thought so.
22:06<shew>Yeah.
22:06<Julian>Ok. SDGathman, what do you think?
22:06<SDGathman>But if readers might get confused, it is always better to be more explicit.
22:07<Julian>Ok, probably right.
22:07<Julian>"... (Older implementations of SPF prohibit trailing dots in domain names, so trailing dots should not be published by domain owners, although they must be accepted by implementations conforming to this document.) ..."
22:07<shew>Yeah, I'd s/those/trailing dots/
22:08<Julian>So let's vote on this sub-change of #25:
22:08<Julian>By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, and so the list of parts may contain empty strings. (Older implementations of SPF prohibit trailing dots in domain names, so trailing dots should not be published by domain owners, although they must be accepted by implementations conforming to this document.) Macros may specify delimiter characters
22:08<Julian>that are used instead of ".".
22:08<Julian>--
22:08<Julian>This paragraph rewording goes hand in hand with the following grammar change (mentioned above several times):
22:08<Julian>domain-end = ( "." toplabel [ "." ] ) / macro-expand
22:08<Julian>--
22:08<Julian>Votes?
22:08<Julian>willix: ping
22:08<shew>I'm going to ignore the fact the the same confusion could make it sound that the domain owners must be accepted by implementations. :-)
22:08<SDGathman>There is a joke about the German professor who lectured for an hour, but saved all his
22:08<SDGathman>verbs for the last 12 minutes.
22:08<shew>YES
22:09<shew>Yes
22:09<Julian>yes
22:09<shew>(shouting accidental.)
22:09<SDGathman>yes on allowing trailing dot with proviso
22:09<Julian>What proviso?
22:10<SDGathman>The warning you proposed.
22:10<Julian>Oh, ok.
22:10<SDGathman>The "should not be published".
22:10<Julian>I'll add that to http://new.openspf.org/draft-schlitt-spf-classic_AUTH48_changes while we're waiting for willix
22:12<willix>I'm ok sorry, I mostly missed last discussions
22:12<willix>what did we end up with?
22:13<SDGathman>Julian is posting to changes.
22:13<shew>We're voting on Julian's text that starts with " So let's vote on this sub-change of #25:" above.
22:13<SDGathman>We ended up allowing trailing dot, but with a "should not publish" note.
22:13<shew>Good summary.
22:14<willix>that is fine, I mean about
22:14<willix>abnf
22:14<shew>Haven't gotten to #34 proper.
22:14<shew>But we're adding ["."] to domain-end.
22:14<willix>ahh
22:14<SDGathman>We deferred completely to RFC 3936.
22:14<shew>that will simplify #34.
22:15<shew>Yeah. I don't think we actually voted on that. But that was the consensus.
22:18<Julian>Ok, while I'm still editing, let's vote on the "defer to RFC 3696" thing:
22:18<Julian>toplabel = <as per LDH rule and additional TLD restrictions in [RFC 3969], Section 2>
22:18<Julian>Votes?
22:19<shew>Yes
22:19<SDGathman>yes
22:19<Julian>yes
22:20<willix>yes
22:23<Julian>So that one's approved.
22:23<Julian>Almost finished editing.
22:25<shew>I see no reason for variant #2 on #35.
22:26<shew>It would prevent entirely-numeric unknown modifiers, for instance.
22:26<shew>Such as 1234=yes
22:27<shew>While that would be confusing, I don't see the point.
22:28<SDGathman>We could have 1337=y
22:28<shew>With variant #1, but not variant #2.
22:31<willix>I'm for #1 as well
22:33<SDGathman>I like #1 best. Unless someone thinks of something that becomes ambiguous.
22:34<shew>Same here.
22:35<shew>Vaguely I wonder if even #1 could be made less strict but...I'd vote for #1.
22:36<SDGathman>I wonder if existing implementations will throw permerror for 3.142=pi
22:36<SDGathman>Trying pysps...
22:37<SDGathman>Nope.
22:37<shew>Heh. cool
22:38<SDGathman>So at least one existing implementation doesn't enforce the name rule anyway.
22:38<Julian>Ok, reload <http://new.openspf.org/draft-schlitt-spf-classic_AUTH48_changes>. What was originally change #34 is now #21, #22, and #36. #35 is now #37.
22:38<Julian>(Reload now.)
22:39<shew>Good.
22:40<shew>I am fine with #21, #22, and #36.
22:41<Julian>Ok, on to #37 (formerly #35). What's the state of the discussion? (Trying to catch up.)
22:41<willix>I would move what you have in "(...)" from 22 into normal sentence
22:42<willix>or add it as separate paragraph with Note:
22:42<Julian>Ok, anyone opposed to dropping the parentheses?
22:42<SDGathman>Dropping parens is fine with me.
22:42<willix>ok with 21 & 36
22:44<Julian>Regarding #37, why do we want to change it in the first place?
22:44<SDGathman>Good point.
22:44<Julian>Was that perhaps an overzealous attempt at liberating domain names while overlooking that "name" doesn't have anything to do with domain names?
22:45<SDGathman>perhaps.
22:45<SDGathman>liberalizing it runs the risk of future modifiers getting permerrors by old implemetnations.
22:45<Julian>True. See the previous discussion...
22:46<Julian>And it wouldn't even really benefit us, would it?
22:47<Julian>I mean, I see the benefit of tolerating trailing dots and such, but what's the point here?
22:47<SDGathman>It is also used in key/value pairs in Received-SPF field.
22:47<Julian>Yes.
22:47<Julian>shew, willix, what do you think?
22:47<shew>sorry. was away for a sec.
22:48<Julian>np
22:48<SDGathman>So liberalizing it might break Received-SPF grammar. We should leave it alone.
22:48<willix>how is leiberating going to break Received-SPF?
22:49<shew>I have the same quesiton.
22:49<Julian>willix: Like with the previous issue we discussed, older implementations that are more strict may break.
22:49<shew>Variant 1 still looks fine to me.
22:49<shew>SDGathman had testes something small there.
22:49<Julian>That was only pyspf.
22:49<willix>Received-SPF is a trace field
22:49<shew>"name" is used for unknown-modifier, key, and identity.
22:50<shew>Right now they can't start with digits.
22:50<SDGathman>What is the point in making it less restrictive?
22:50<Julian>willix: But SPF MUA implementations may have to parse this trace field, and older implementations may not like "name"s that start with digits, etc.
22:50<Julian>I see no point either.
22:50<Julian><Julian> Was that perhaps an overzealous attempt at liberating domain names while overlooking that "name" doesn't have anything to do with domain names?
22:51<SDGathman>I think so.
22:51<shew>I guess you're right. If it affecte a domain name such as "3stooges.com", that's one thing. But I suppose if it just affects a modifier such as "3stooges_funny=yes", then..that's harder to justify a change.
22:51<shew>to justify a change for.
22:51<SDGathman>#37: no
22:52<Julian>Votes on #37?
22:52<shew>#37: no
22:52<Julian>#37: no
22:52<willix>I would prefer change, the name should accept string that is like a domain name
22:52<willix>#37 variant 1: yes
22:52<Julian>#37 rejected (3x no, 1x yes)
22:52<SDGathman>willix, you envision something like "my.domain.com=super-charged" ?
22:52<willix>yes
22:53<willix>for future extensions this is useful
22:53<shew>willix: I'm willing to reconsider if you can present a reason why an unknown-modifier, key, or identity should be allowed to start with a digit.
22:53<shew>At the expense of possibly causing permerrors.
22:53<willix>future extensions of spf may need it for trace data
22:53<SDGathman>Anything you could do with "domain.com=bar", can be done more safely with "bar=domain.com".
22:54<willix>I prefer to be more liberal with what is listed for unknown
22:54<SDGathman>It is too late for that without risking permerrors.
22:54<Julian>"my.domain.com=super-charged" -- This is wrong, because it's namespace overloading. The right thing to do might be: "super-charged_my.domain.com=y". That would work even with domains that start with a digit.
22:55<Julian>And we can't be arbitrarily liberal now. This is about "SPF Classic".
22:55<shew>"5nines=yes" wouldn't work.
22:55<SDGathman>That would have been a good decision back in 2003.
22:55<Julian>"five-nines=yes" would work.
22:55<SDGathman>shew, but five_nines=yes would work.
22:56<shew>Do any implementations actually give permerrors for this?
22:56<shew>If not...
22:56<willix>data=k: 1.0=data 1.1=data2
22:56<SDGathman>We don't have time for an exhaustive test.
22:56<willix>data=k: 1.0=data 1.1=data2
22:56<Julian>"x-5nines=yes" would work also, although not via { key = "x-" name }, but via { key = name }.
22:56<willix>"data=k: 1.0=data 1.1=data2"
22:56<SDGathman>data1=1.1 data2=1.2
22:56<willix>data=k ":" 1.0=data 1.1=data2"
22:57<willix>all right, lets rap it up
22:57<Julian>Ok.
22:57<Julian>Thanks to you all.
22:57<shew>Wait.
22:57<shew>The #spf-private thing.
22:57<Julian>Yes.
22:57<willix>ok, seems I again dont see the chat log...
22:57<Julian>LOL
22:57<willix>will reconnect in a sec
22:57<Julian>BitchX sucks.
22:58<Julian>(no pun intended)
22:58<Julian>Well, there's one more issue that I think needs to be discussed urgently.
22:59<Julian>On our last meeting (not counting yesterday), we decided to make an announcement about the council and the project agenda.
22:59<Julian>What's the status of that?
22:59<shew>I haven't done it. I'll be home tomorrow afternoon and will do it.
22:59<shew>I'll update on #spf as I'm writing.
23:00<willix>send draft to spf-council mail list and we'll comment
23:00<shew>ok
23:00<Julian>Ok.
23:00<Julian>So there's one other thing I'd like us to discuss briefly.
23:00<Julian>Please join #spf-private for that.
23:01<willix>Julian, can you also finish updates to the AUTH48 and give until end of today before sending it to Meng
23:01<willix>Just to make sure everything is right. Any comments would be on the mail list
23:01<Julian>Ok.
23:02<Julian>SDGathman: Please join #spf-private also.
23:02<SDGathman>ok
23:02<Julian>SDGathman: I mean the IRC channel.
23:02<Julian>#spf-private
23:12<Julian>Ok. Motion: Adjourn this meeting.
23:12<SDGathman>seconded
23:12<Julian>Votes?
23:12<Julian>yes
23:13<shew>yes
23:13<SDGathman>yes
23:13<Julian>I assume a "yes" from willix.
23:13<Julian>The meeting is hereby adjourned. Thank you!
23:13<willix>yes
23:15<willix>next time lets try satarday. But it is good that we could when it was necessary get together that quickly though

This report was generated at Tue Mar 28 23:59:59 UTC 2006.