[Top] [All Lists]

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

2005-03-02 21:55:13

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.