ietf-mxcomp
[Top] [All Lists]

Re: why we should not be ambiguous about receiver behaviour

2004-04-23 14:45:57

wayne wrote:
In <E1BGwCO-0007Lr-Hq(_at_)argon(_dot_)connect(_dot_)org(_dot_)uk> "Jon Kyme" 
<jrk(_at_)merseymail(_dot_)com> writes:
...
handwaving descriptions of how validation might work.  If the
algorithm hasn't been defined and tested by now,

I'm not sure what you're proposing here, time travel?


I am suggesting that we start a split track now.  The RFC2821 stuff
has been held back far too long.  The RFC2822 algorithm (S/MIME, DK,
C-ID, something else) needs to be selected and then tested.  We
shouldn't abandon either one.



If you are proposing a split track, than we need to figure out how to do it. If you don't let the publisher indicate the type of identity, then you need some other way to extend the MARID records to allow for 2822 checking later.

Hmm, another way of doing this is as Andy originally said - let the domain owner publish the data without an identity, and start defining two algorithms for verification of it. The receiver will have a choice of either one of use. We can start with 2821 and define 2822 later.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
-------