----- Original Message -----
From: "Michael R. Brumm" <me(_at_)michaelbrumm(_dot_)com>
To: "IETF MARID WG" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, June 22, 2004 6:35 AM
Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re
cords]
Greg Conner wrote:
(One sort of limiting factor about modifiers is that they are considered
to
be order-independent and the current spec encourages them to be placed at
the end to make this clear. If I were to propose any modification to the
current spec, it would be to allow modifiers to be placed inline allowing
for the possibility that they might apply/associate the terms appearing
after them, if appropriate. This minor change in the spec should not
affect any current parser or published records and would just be a
clarification...)
Out of all the SPF spec changes proposed in the name of "extensibility" in
the last couple months, I'd have to say that IMHO, this is probably the
most reasonable. I'd vote for it.
hmmm, Michael, I think it would be better for SPF to being a new version
number at this point with the goal of cleanly defining its new needs. A
"V=SPF2" or whatever where the client software would have new and clearer
functional specifications in the implementation. For V=SPF1, clients need
to continue to support the original functional specs in order to support
legacy systems. A legacy client can't be broken with a SPF1 record now
having unexpected "parts," including having unknown extensions before the
ALL directive or trailing the ALL directive.. Trailing Extensions is a
lesser issue, but its support is limited to only those clients that expects
the trailing extensions.
SPF2 clients will be backward compatible and easily handle both. SPF
Documentation won't be a mess. It will be clearly separated - a clean slate
to move forward with a new "clean" format and more importantly with MARID in
mind, without inline kludges and conflicts with directive processing order
presented with attempting to add extensions.
From a sysop or domain standpoint, if he wants the use the core original SPF
features, then he would define a traditional V=SPF1 without any SPF2
features. This will give him the widest support for legacy SPF1 system and
new SPF2 systems. But if he needs SPF2 features, then he would use V=SPF2.
Period. Lets not confuse the design. After all, using SPF2 features in a
SPF1 record will mostly break the rule processing in legacy SPF1 clients
anyway so he is limited to SPF2 systems only. I don't see that as an issue.
He will understand that the feature set chosen is only doable with old or
new systems anyway. A neat straight forward "Feature/Version Table" will
illustrate this to the sysop and help him decide what's he needs.
Also, with the new SPF2 specification, it could include a possible
provision for domains to defined both records if so desired. SPF1 clients
will only read SPF1 and SPF2 clients will read the SPF2 record. The issues
regarding duplicity or large record requirements will have to be something
the sysops needs to weight. I see this as a now issue.
From my standpoint, this will make it easier for me to implement, easily to
explain and document for sysop/customers to decide.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com