[ietf-dkim] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))
tony at att.com
Mon Sep 22 14:02:41 PDT 2008
+1 on moving forward with draft-ietf-dkim-ssp.
After re-reading it afresh, a couple nits are noted below.
tony at att.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:
< [RFC2821], Local-part comparisons are case sensitive, domain
< comparisons are case insensitive.
> [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
< 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
> 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
> I'll give folks the weekend to check that and for any
> new typos then send the publication request to Pasi.
> Thanks all,
> John L wrote:
>> This addresses the various last call comments. The changes are all minor
>> editorial ones, nothing large.
>> John Levine, johnl at iecc.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.org>
>> To: standards at taugh.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
>> 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
> NOTE WELL: This list operates according to
More information about the ietf-dkim