----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <domainkeys-feedbackbase02(_at_)yahoo(_dot_)com>; "IETF MASS WG"
<ietf-mailsig(_at_)imc(_dot_)org>
Sent: Wednesday, July 27, 2005 12:06 AM
Subject: The cost of choices
Whether operators choose to use all the features is a separate matter, but
as
Mark notes, there is a problem if the initiating side uses it but the
receiving side does not.
I brought this up in my response to your poll. Did you read it?
http://www.imc.org/ietf-mailsig/mail-archive/msg01718.html
The suggestion is that q=DNS query be the standard fallback and that a
extended SIGNER using some other "q=" query method must also publish the
DKIM policy in DNS as well to support the fallback on non-compliant extended
query DKIM receivers.
This allows us to concentrate on using DNS.
But we should model the specification based on a standard Input/Output
Model:
Standard:
DKIM_POLICY = DKIM_DNS(selector, domain)
Extended DKIM query protocols:
DKIM_POLICY = DKIM_XKMS(selector, domain)
DKIM_POLICY = DKIM_SOAP(selector, domain)
DKIM_POLICY = DKIM_other(selector, domain)
These extender protocols would be out of scope for the core DKIM
specification, but I think the core should include a simple modeling thus
allowing future query methods to be invented.
So I think, the only thing that needs to be clearly defined is what are the
minimum CORE expected input and output variables. I think this is already
established. So it just a matter of modeling it in the specs.
A separate DKIM-QUERY ID draft can be written that follows the DKIM-core
draft.
Make sense? If not, please let me know what I am not seeing here that makes
this more difficult than it is?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com