Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

> 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