On Wed, 02 Aug 2006 08:28:20 -0500 wayne <wayne(_at_)schlitt(_dot_)net> wrote:
In <44D03872(_dot_)5090601(_at_)dcrocker(_dot_)net> Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> writes:
John L wrote:
SSP exists so that receivers can make better decisions about
handling their incoming mail.
Corollary:
Information not useful to receivers doesn't belong in SSP.
I agree, but it is also important to remember that anything that has
no value to the sender will likely not be put into the SSP either.
For this initial round of SSP, the wording of the Corollary probably
needs to be:
Information that is not widely viewed by receivers as essential
doesn't
belong in SSP.
I think this is very short sighted. It is rare that a protocol gets
more than one or two revisions. I don't think it is certain that DKIM
will actually even surpasses DK usage and receives wide adoption, but
I think it is very unlikely that we will get a chance to update DKIM
and have that update receive wide adoption.
There certainly should be a cost/benefit analysis done. If a feature
is costly to add and has little obvious benefit to both senders and
receivers, then, yeah, drop it. However, if a feature is cheap or
trivial to add, then just because there aren't people willing to use
it *immediately* is no reason to rule it out. And, yes, the overall
complexity of the SSP system needs to be added into the cost, I'm not
saying that all features that, in isolation, are "cheap" should be
added, just that we shouldn't design SSP for only today and not for
5-10 years down the road.
+1
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html