I think that there is plenty on policy to keep us busy.
I see three (related) questions:
1) What is the range of policy statements that should be supported?
PHB: [DKIM[=keyselector]? ] *
(signing is all or nothing, multiple signatures may be
specified).
Others: ?
(does anyone argue for DKIM-Somethines as an actionable policy)
2) What syntax should be supported?
PHB: Tag-value pairs, DKIM is a tag
Other possible extension tags are for other protocols: SPF,
PHISHED, DKIM-TEST, SMIME, PGP, etc.
Others: ?
(This answer depends on the andswer to 1, if you have a great
deal
of expression in your policy language then a DKIM language
might
be appropriate).
3) What should the discovery mechanism be?
PHB: Finese the wildcard issue with a pointer record
Reuse of PTR prefered but a new RR is acceptable
Others: ?
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
Sent: Wednesday, February 21, 2007 10:01 AM
To: Barry Leiba
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] draft-ietf-dkim-base-10 submitted
Barry Leiba wrote:
The DKIM base draft has been updated and submitted. The
changes are
minimal, comprising response to IESG review and some XML updates
intended to smooth the rfc-editor review.
And the -base-10 draft is now on its way to the RFC editor
queue,[1]
having passed IESG review. Many thanks to everyone who
worked to get
this done. And now we just wait for the RFC editor
process, and the
RFC number for the Proposed Standard.
And get active on SSP again. (Or should I cancel the Prague
meeting slot? So far we've little to discuss it seems.)
S.
_______________________________________________
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