On 08/30/2010 08:03 PM, Murray S. Kucherawy wrote:
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, but see my previous message about normative vs informational.
(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.
Removing signatures/traces because
a) some domains don't know how to use ADSP and/or
b) some assessors don't implement RFC4871 correctly
sounds like a bad idea to me. The best the document can do here, is to
describe what are the pro's of keeping signatures and what are the pro's
of removing them, in an operational environment.
(3) Something else (and specify what that might be).
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.
I'll try to review the -02 version in the next couple of days.
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.
IMO MLM's need a re-design to bring them in line with today's e-mail
technologies, but inevitably this will lead to (new) MUA requirements.
As these things only have a small (or no) DKIM component I fully agree
to move that work to another list.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html