While I'm very interested in learning about things that SPF
implementations usually do that aren't (adequately) document, or
things that are documented that most SPF implementations don't do,
there are still a few things that are being changed around the edges.
Basically, the more incompatible the suggested change, the more
evidence will be required that it is a *really* important and
necessary change.
If I may make a suggestion -
I have generally found that when documenting an existing protocol it's
important to pick one of two goais:
1) document the protocol as it is used in practice, or as it was used
as of a particular date
2) document how the protocol SHOULD work
trying to do both tends to produce a document which is effective at
neither. often the legacy protocol has enough shortcomings (whether
these are actual bugs or new features that people demand) that trying
to solve all of those shortcomings delays completion of the
specification until it is no longer relevant. or if you're trying to
document how the protocol SHOULD work then you often need to deprecate
or discourage features of the legacy protocol. if nothing else, trying
to intermix new features (not supported in the legacy protocol) and
features of the legacy protocol which should be deprecated tends to
produce a confusing document. and when people try to use that document
as a basis for new implementations, you get more interoperability
problems as a result.
(a good example is RFC 1179, which did a poor job of documenting the
LPD protocol, and also tried to define some new features of dubious
value. the result is that RFC 1179 actually degraded interoperability
of the LPD protocol rather than improving it)
so if you're going to document how the protocol is/was used in
practice, resist the temptation to define new features. if you must
define new features, get the text about the old features settled first,
and put the new features in a separate section (or appendix) in order
to clearly distinguish the new features from the old ones. and while
it's probably useful and appropriate to point out things about the
legacy protocol that didn't work well, it may be a good idea to put
those in a separate section also.
another nice thing about documenting how the protocol is/was used is
that you can avoid a lot of controversy on whether or not the protocol
is a good idea. you're just documenting something for the record, not
trying to get consensus on a recommendation. the only controversies
should be about whether you're documenting the protocol accurately, and
perhaps about whether you're doing due diligence in pointing out any
hazards (e.g. security or operational considerations) associated with
the legacy protocol. for instance it would seem appropriate to point
out the conflicts between the assumptions that SPF makes regarding use
of SMTP protocol data elements and/or 822 header fields, the way these
fields are specified, and they way they're actually used in practice.
otoh, if you're going to document how the protocol SHOULD work, then
put the deprecated features (if any) in a separate section. and be
prepared to take a couple of years to get consensus on the document, as
people try to get it to be all things to all people. (frankly I think
that there's a limit to how effective any proposal in this space can
be, and it's probably not worth the trouble to try to make SPF be the
ultimate email authentication scheme. and I'd say the same thing about
the other authentication proposals I've seen)
but it sounds like you're trying to do the former.
Keith