On Tue, 04 Dec 2007 04:23:27 -0000, John Levine <johnl(_at_)iecc(_dot_)com>
wrote:
The biggest problem with this draft is that it goes way beyond
defining a protocol.
True. Essentially. we have standards track documents and we have BCP (Best
Current Practice) documents, and indeed SSP could have been published as a
standards/BCP pair. However, I accept that including BCP material in a
standards track document is often more convenient and is reasonable
*provided* it is clearly delineated from the normative stuff.
So SSP can clearly define, Normatively, what signers can say in their SSP
records, and in what notation, and can say what their statements "mean"
(that is, the semantics). Thus SSP supplies a mechanism for signers to
transmit information with defined meaning to verifiers (and anyone else
who cares to look at it); and defining such mechanisms is exactly what
IETF standards are all about.
But it has no business whatsoever making normative statements about what
verifiers are to do, so wording of the form "Verifiers MUST" is quite out
pf place - that is BCP material.
{Actually, RFC 2119 does admit, in its usual woolly sort of way, that
MUST/SHOULD/MAY might be interpreted differently in non-standard
documents, so you might define those words as having a different
interpretation in BCP sections.}
Part of it describes the way that senders publish statements about
their sending practices and the way that receivers can look for those
statements, which is fine, but the rest attempts to tell receivers
what to do with mail they have received, which is not.
What it does (or should do) is to define, Normatively, what SSP signers
can say. That seems to cover two areas:
1. This is what we *do* (or do not do) when signing (or not) things.
2. This is what we *advise* (or even "expect") verifiers to do with the
information we provide.
It really needs to back up and define how a sender publishes its
policy, how a recipient can look up a policy if it wants to do so,
then stop. That's all they need to interoperate.
But that is going too far. It covers my #1, but not my #2, which includes
important stuff such as the 'strict' and 'deny' features.
And I am still happy to see BCP material which then, essentially,
describes ways in which verifiers are "expected" to apply the "advice".
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html