ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))

2008-09-22 18:08:13
+1 on moving forward with draft-ietf-dkim-ssp.

After re-reading it afresh, a couple nits are noted below.

        Tony Hansen
        tony(_at_)att(_dot_)com

    Please replace RFC 2821 with draft-klensin-rfc2821bis. The latter is
    in AUTH48 to be published as RFC 5321 and will obsolete 2821.
    Changing it now will guarantee that it will get fixed up to be the
    proper reference during ADSP's AUTH48.

    Please replace RFC 2821 with draft-resnick-2822upd. The latter is in
    AUTH48 to be published as RFC 5322 and will obsolete 2822. Changing
    it now will guarantee that it will get fixed up to be the proper
    reference during ADSP's AUTH48.

    Section 2.7, 1st para, missing conjunction:

    <                                                   Following
    <   [RFC2821], Local-part comparisons are case sensitive, domain
    <   comparisons are case insensitive.
    --
    >                                                   Following
    >   [RFC2821], Local-part comparisons are case sensitive, and domain
    >   comparisons are case insensitive.

    Section 4.1, 3rd para, missing space:

    <   ADSP records MUST NOT be published at any location other than
    <   the_adsp._domainkey subdomain of the domain for which they are
    --
    >   ADSP records MUST NOT be published at any location other than
    >   the _adsp._domainkey subdomain of the domain for which they are

    Section 4.2.1, 1st para, should eliminate record starting with
"dkimXYZ=":
    <   practices tag, so the first four characters of the record are
    <   lower case "dkim".
    --
    >   practices tag, so the first four characters of the record are
    >   lower case "dkim", followed by optional whitespace and "=".

    Section 4.2.1, 6th para, clarity:
    <   a path without access to a signing key, or other reason, the
    --
    >   a path without access to a signing key, or any other reason, the
    or
    >   a path without access to a signing key, or another reason, the

Stephen Farrell wrote:
Thanks John,

So this means that we're not taking on board the various
suggestions in Doug's draft since they didn't garner
any real support. I think that's correct, but just in
case - if there's a whole bunch of folks out there who
agree with Doug's draft so much that they think we
should not progress ADSP - now's your last chance
(in the WG) to say so.

It might be no harm if folks who do think ADSP should
go ahead would respond to this saying so. I'm sure that
Doug will (quite reasonably) bring up his concerns again
at IETF LC, so being crystal clear here might be no
harm.

I'll give folks the weekend to check that and for any
new typos then send the publication request to Pasi.

Thanks all,
Stephen.

John L wrote:
This addresses the various last call comments.  The changes are all minor 
editorial ones, nothing large.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---------- Forwarded message ----------
Date: Fri, 19 Sep 2008 14:17:07 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission(_at_)ietf(_dot_)org>
To: standards(_at_)taugh(_dot_)com

A new version of I-D, draft-ietf-dkim-ssp-06.txt has been successfuly 
submitted by John Levine and posted to the IETF repository.

Filename:     draft-ietf-dkim-ssp
Revision:     06
Title:                DKIM Author Domain Signing Practices (ADSP)
Creation_date:        2008-09-19
WG ID:                dkim
Number_of_pages: 21

Abstract:
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages.  This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address.  It defines a
record that can advertise whether a domain signs its outgoing mail,
and how other hosts can access that record.



The IETF Secretariat.


_______________________________________________
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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>