Subject: [ietf-dkim] draft-ietf-dkim-base-02 submitted

From: Eric Allman <[email-masked]>
Date: Mon, 22 May 2006 17:04:33 -0700

I've just submitted the -02 version of the DKIM base spec.  You may 
find it at one of

    http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-02.html
    http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-02.txt

This does incorporate the changes we discussed in last week's jabber 
session.  At least, I hope I got them all.

eric
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 23 May 2006 05:56:47 -0400

Eric,

Just a few minutes to review this.  I noticed you introduced a series of
DKIM_STAT_xxxxxx status literals which I personally agreed with in a
previous message as a good idea.

But it is scattered all over the place. It would be nice to consolidate all
of these into a table and a new section, possibly 3.8 or appendix?

Here is a suggestion/start:

3.8 DKIM Status values:

  STATUS                    Description, index to sections?

  DKIM_STAT_something       Open ended for implementers, 6.0
  DKIM_STAT_PARTIALSIG      part of message signed, 6.0, 6.3
  DKIM_STAT_INVALIDSIG      Invalid signature, 6.3
  DKIM_STAT_TEMPFAIL        can not be verified, 6.0, 6.2
  DKIM_STAT_SYNTAX          signature syntax problem, 6.1,
  DKIM_STAT_INCOMPAT        version conflict (v=), 6.1,
  DKIM_STAT_EXPIRED         signature expired (x=) 6.1,
  DKIM_STAT_NOKEY           No DNS Public Key, 6.2,
  DKIM_STAT_INAPPLICABLE    Conflicts Ignored????, 6.2
  DKIM_STAT_REVOKED         Revoked key (p= empty), 6.2

This can be part or even become the desired section of possible failures
that is on the issues list.

Thanks and have a good day.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Eric Allman <[email-masked]>
Date: Tue, 23 May 2006 11:03:05 -0700

Hector,

I thought about doing something like that but decided that to do so 
would be inappropriate since these are informative, not normative. 
Note the text in paragraph of section 6:  ``Note that an 
implementation is not constrained to use these status codes; these 
are for explanatory purposes only, and an implementation may define 
fewer or more status codes.''  In particular, they are not "protocol 
elements" (the topic of section 3), so if I were to collect them 
together, it would be in an appendix.

DKIMers: Any other thoughts on this?

eric

--On May 23, 2006 5:56:47 AM -0400 Hector Santos 
<[email-masked]> wrote:

> Eric,
>
> Just a few minutes to review this.  I noticed you introduced a
> series of DKIM_STAT_xxxxxx status literals which I personally
> agreed with in a previous message as a good idea.
>
> But it is scattered all over the place. It would be nice to
> consolidate all of these into a table and a new section, possibly
> 3.8 or appendix?
>
> This can be part or even become the desired section of possible
> failures that is on the issues list.
>
>> This does incorporate the changes we discussed in last week's
>> jabber session.  At least, I hope I got them all.
>>
>> eric

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 23 May 2006 14:51:33 -0500

> DKIMers: Any other thoughts on this?

An appendix would be good for this.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 May 2006 14:46:05 -0700

Folks,

> I've just submitted the -02 version of the DKIM base spec.  You may find

Latest versions of -base and -threats are now on the dkim.org web site.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html