wayne wrote:
* djbdns only returns 8 RRs instead of the complete RRset
(e.g. add a warning that some resolvers are known to give
incomplete information and using them in conjunction with
SPF checks can lead to errors.)
Is this related to the output of `nslookup -q=any`, or what is
it about ?
* it is easier to convert IPv4 to IPv6 and work with just
that (this is just an implementors note.)
Better don't add it to the spec. then. It really confused me
when Julian talked about it after his MAAWG hacking session.
So far the spec. was always right for all imaginary IPv6 vs.
IPv4 "problems". If it isn't broken don't fix it.
* bugs in the ABNF
* "redirect=aaa" is accepted by 'name "=" macro-string'
instead of being rejected.
IIRC it's impossible to fix this, or do you have an idea ?
Maybe 'name "=" domain-spec' ?
* "a:ab%-" is accepted because <domain-end> uses
<macro-expand>
Yes, so what ? You can't kill _all_ semantical issues in ABNF.
* CIDR values are not checked for the ranges
In that case it was possible, but on the border to "too ugly".
all of these were fixed in the ABNF that I posted a while
back.
I recall only the last point (CIDR values). Please post it
again if it also addresses the other two points.
For what it is worth, I have had no indication that the RFC
editor has done anything with the SPF I-D.
Waiting for 2234bis.
At this rate, it could be many months before the SPF I-D
becomes an RFC.
Sure, four months was the _average_ delay calculated by Bill,
not the worst case. As long as 2234bis has no RfC number SPF
is just sitting there and waiting. Maybe it's some ritual of
Scott to promote 2234bis: Get more and more RfCs waiting for
2234bis in the queue, until this triggers an RfC-editor alarm,
and they do something about it. Or until Dave fixes his MTA.
Bye, Frank