Julian Mehnle wrote:
>> We could decree that it's invalid in chapter 4.8 for consistency with
>> the <domain-spec> construct always requiring more than one label (in
>> the absence of macros).
[...]
> You didn't understand what I said. We cannot add this to v=spf1, EVER.
Of course we can. In theory we can approve the damned erratum as is,
I think at the moment it reflects Stuart's appproach. On their way
from Proposed Standard to Full Standard specifications can do what you
see when comparing RFC 1738, 2396, and 3986 (a rather extreme case)
Or do what they did with UTF-8 over the years. 31 bits code points,
anybody ? That's the purpose of this "three steps" standardization,
and SPF even got a fourth step. There are rules what you can do, and
what you can't do, tons and tons of rules. The time you're seriously
forced to consider "maturity" is Draft and Full Standard.
They have _added_ IPv6 to URLs in RFC 3986 (STD 66, just an example).
They did stuff with URLs that forced us to write an erratum. In that
case our fault, but it would be similar with SPF published earlier.
> existing implementations would have to undergo significant changes
> in order to remain compliant.
That's the purpose of a "proposed standard" (let alone "experiment"):
| Implementors should treat Proposed Standards as immature
| specifications. It is desirable to implement them in order to gain
| experience and to validate, test, and clarify the specification.
| However, since the content of Proposed Standards may be changed if
| problems are found or better solutions are identified, deploying
| implementations of such standards into a disruption-sensitive
| environment is not recommended.
Yes, there are differences between RFC 2026 theory (1996) and common
practice today, but they're nowhere near to your rigid assumptions.
And almost completely beside the point for an experimental RFC.
Of course we'd care about side-effects of changes introduced in the
future revisions of v=spf1 (and picking another version tag is one
desperate way to address it if necesary), but that's it.
If 4408bis and 4408ter work with almost all v=spf1 policies published
since early 2004 it's far more than only good enough. As far as I'm
concerned. Users will update include_subdomains=yes default=fail as
needed, or bite (again just an example).
Frank
-------
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/?list_id=735
>> We could decree that it's invalid in chapter 4.8 for consistency with
>> the <domain-spec> construct always requiring more than one label (in
>> the absence of macros).
[...]
> You didn't understand what I said. We cannot add this to v=spf1, EVER.
Of course we can. In theory we can approve the damned erratum as is,
I think at the moment it reflects Stuart's appproach. On their way
from Proposed Standard to Full Standard specifications can do what you
see when comparing RFC 1738, 2396, and 3986 (a rather extreme case)
Or do what they did with UTF-8 over the years. 31 bits code points,
anybody ? That's the purpose of this "three steps" standardization,
and SPF even got a fourth step. There are rules what you can do, and
what you can't do, tons and tons of rules. The time you're seriously
forced to consider "maturity" is Draft and Full Standard.
They have _added_ IPv6 to URLs in RFC 3986 (STD 66, just an example).
They did stuff with URLs that forced us to write an erratum. In that
case our fault, but it would be similar with SPF published earlier.
> existing implementations would have to undergo significant changes
> in order to remain compliant.
That's the purpose of a "proposed standard" (let alone "experiment"):
| Implementors should treat Proposed Standards as immature
| specifications. It is desirable to implement them in order to gain
| experience and to validate, test, and clarify the specification.
| However, since the content of Proposed Standards may be changed if
| problems are found or better solutions are identified, deploying
| implementations of such standards into a disruption-sensitive
| environment is not recommended.
Yes, there are differences between RFC 2026 theory (1996) and common
practice today, but they're nowhere near to your rigid assumptions.
And almost completely beside the point for an experimental RFC.
Of course we'd care about side-effects of changes introduced in the
future revisions of v=spf1 (and picking another version tag is one
desperate way to address it if necesary), but that's it.
If 4408bis and 4408ter work with almost all v=spf1 policies published
since early 2004 it's far more than only good enough. As far as I'm
concerned. Users will update include_subdomains=yes default=fail as
needed, or bite (again just an example).
Frank
-------
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/?list_id=735