So many choices, so little time..... > From: [email protected] [mailto:[email protected]] > On Behalf Of Murray S. Kucherawy > Sent: Monday, August 30, 2010 2:04 PM > To: [email protected] > 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
