On May 9, 2009, at 11:06 PM, Eliot Lear wrote:
On 5/9/09 2:01 AM, John Levine wrote:
with some editorial changes I guess. I've not seen anyone suggest
that we add features or remove a raft of features or make other
substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
I like deprecating useless stuff, but before we do that I would like
to see broader implementation, and again, specifically in mailing
list managers, before we decide what is useless.
Agreed. It appears merging errata now means explaining once again why
features were included and why their possible use should be supported,
even if only to generate clueful error messages. It may takes years
before issues being addressed by some feature becomes apparent. This
may occur only after greater adoption and MUA integration where
reliance and annotations make their impact perhaps several years from
now.
For example, providers may insist upon adding a disclosure
notifications at the end of emails. The l=value, when used
appropriately and is properly supported, could ensure a message
remains in an state that will not prohibit non-repudiation, by being
explicit about the body length. This feature may also allow providers
a means to escape the hashing large attachments, for example.
DKIM is too new. Anything looks complex until people get used to it.
I also fear there are those with conflicted interests which might wish
to emasculate DKIM to better enable competing strategies. DKIM needs
to be better protected from change based upon one's perception of
complexity.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html