So many choices, so little time.....
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org]
On Behalf Of Murray S. Kucherawy
Sent: Monday, August 30, 2010 2:04 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] Proposed changes to MLM draft
I'd like some help tackling the next version of the MLM draft. People
seem
to have varying ideas about what should be removed and perhaps appear
in
other documents now. I need some consensus on a direction in which to
proceed.
So can I please get some +1s/-1s on each of the following:
(1) Split the document into three documents: A DKIM MLM BCP that
discusses
signing and verifying in the context of MLMs with no value-add items
addressed, a DKIM MLM Informational that discusses possible value-add
enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing
lists
irrespective of DKIM (Dave's proposal);
-1 Do we need as many documents to describe the tail as we need to
describe the dog?
(2) Tear out everything having to do with making author signatures
survive
list relaying, dropping all that text altogether, and instead pointing
people at S/MIME or PGP (John's proposal);
-1 John's proposal is that we leave MLMs alone to do their thing, but in
such a way that it is codified in the working group document. He has
inserted himself into this process in a manner similar to what he did to
ADSP. If we are seriously going to consider tearing out everything
having to do with making author signatures survive list relaying then I
think another option should be considered - The working group should
drop any attempt to write a document specific to MLMs. Some will operate
in a way compatible with DKIM and others will choose not to.
S/MIME and PGP are out of scope for the working group. It would be
ironic for the DKIM working group to point people somewhere else. It is
essentially an acknowledgement that DKIM is a failure in that the
working group would be expressing a belief that it is not possible for
signatures to survive MLM handling under any circumstances. If it is
possible for DKIM signatures to survive then why the opposition to
documenting such implementations.... could it be potential pressure to
change and evolve? Darwin was right.... evolve or die.
(3) Something else (and specify what that might be).
Drop the effort to write a document specific to MLMs and leave each one
to sink or swim on their own decisions....
AND...
If you support any of the above, please take a few minutes to include
some
pointers to what text you want changed/exported and in what way.
Actual
diffs would be ideal, but I'll take point-form commentary as well.
AND...
If you advocate for a general MLM BCP, this will be a non-WG document
(it's
outside of our charter) so I'd love to get some MLM operators and
developers
involved. (Maybe this should take place on ietf-822 or maybe on a new
non-WG list; suggestions welcome.) Expressions of interest in that
work
would be appreciated. I'll approach the APPS ADs about a venue.
Thanks,
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html