-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Last minute changes:
== proposed ==
domain-end = ( "." toplabel [ "." ] ) / macro-expand
== original ==
domain-end = ( "." toplabel ) / macro-expand
==============
Two occurences (9.1 and collected ABNF). This introduces an
unnecessary incompatibility with an unknown number of existing
SPF and SenderID implementations, for an example see
<http://permalink.gmane.org/gmane.mail.spam.spf.discuss/20813>
First, this change doesn't actually introduce an incompatibility. The
changed spec explicitly says that trailing dots should not be published,
however it allows implementations to accept them when encountered anyway.
As for actually breaking implementations: M:S:Q doesn't count; it deviates
from the spec in more than a few aspects and will hopefully be replaced by
Mail::SPF soon. As Stuart said, pyspf will normally accept trailing dots.
As far as I can tell, libspf2 does accept trailing dots. I haven't
checked any other libs, though (including libspf).
Therefore I recommend to disregard this proposal, or get a 3rd
opinion from John C. Klensin, the author of RFC 2821 and 3696.
The council has carefully weighted the pros and cons and has concluded
that, given the warning about publishing trailing dots that has been added
to the spec, the change benefits more than it does harm. This is not an
attempt at "proof by authority", but the issue was controversial on
spf-discuss and _some_ decision had to be made, so the council members'
personal opinions played a role.
== proposed ==
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
; LDH rule (See [RFC3696])
== original ==
toplabel = <TLD label as per [RFC3696], Section 2>
; LDH rule plus additional TLD restrictions
==============
This prose specification is rather clumsy. RFC 3696 is an
informational RFC, not suited for a normative reference.
You do have a point, however we're only "Experimental" (yes, this is an
excuse, but not necessarily a bad one).
The intention is okay, but at this time there exists no RFC with a
proper ABNF for the "not only digits" LDH rule for toplabels.
True, however not even HTTP (RFC 2616) specifies in its ABNF grammar what
constitutes a host name, let alone a TLD. It refers to RFC 2396, which
has been replaced by the somewhat recent RFC 3986 ("Uniform Resource
Identifiers (URI): Generic Syntax"), which in turn just refers to RFC
1034.
See draft-ietf-usefor-usefor-07 for a first attempt in this direction.
Interesting. (Going from your earlier pointer in the USEFOR direction, I
had searched the various drafts for a "toplabel" or equivalent definition
but couldn't find one, probably because I was in a hurry and accidentally
skipped usefor-usefor-07.)
But we don't have "label" defined, which is required by the USEFOR
definition of "toplabel", so we'd have to copy that, too, just for the
sake of an anal-retentive definition of "toplabel".
I see that the RFC Editor did NOT apply[1] our changes completely (for
example the changes to the ToC are missing), so we'll have to submit
another -- hopefully VERY BRIEF -- list of changes. If someone can come
up with a TERSE and NOT OVERLY COMPLEX definition of "toplabel" (something
along the lines of USEFOR's "toplabel" and "label" definitions merged and
simplified), then perhaps we can include it.
References:
1. http://archives.listbox.com/1943/200603/0049.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFELU82wL7PKlBZWjsRAuBWAKDjhZ6c+Y6D5OIaw/PNIWVYEAdKqgCg1U6l
EAxqFDMplsn6/fcJive/1X8=
=/ImA
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com