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

[Tony Hansen <[e-mail]>]

+1 on moving forward with draft-ietf-dkim-ssp.

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

	Tony Hansen
	[e-mail]

    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, [e-mail], 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 <[e-mail]>
>> To: [e-mail]
>>
>> 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