> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Dave CROCKER > Sent: Friday, December 02, 2011 3:59 PM > To: SM > Cc: ietf@xxxxxxxx > Subject: Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC > > On 11/30/2011 12:34 PM, SM wrote: > > "Readers should be familiar with the material and terminology > > discussed in [MAIL] and [EMAIL-ARCH]." > > > > The references to RFC 5598 and RFC 5322 should be normative. > > Arguably, they already are: the text says "should" and that's a > normative term in the document... (but no, I doubt Murray, really > intended it and for some odd reason, I agree both docs /should/ be > normative...) Yes, I've already changed my working copy. > > In Section 3: > > > > "An Author participates in this protocol if it wishes to announce that > > a message from it (in the RFC5322.From sense) should be considered > > authentic as long as it bears a signature from any in a set of > > specified domains." > > > > It's the domain and not the author which participates in this > protocol. > > +1 > [...] The working copy now uses ADMD. > > The Abstract section uses the term "authorization" whereas "authentic" > > is used in the above text. Shouldn't that be "considered as authorized"? > > +1 on the concern about using the correct term. > > The document needs to be much more clear and precise about this, since > it is the essential semantic behind the spec and I think the current > text is a bit confusing in that regard. SM and I agreed that changing it to "authorized" and also making reference to Section 1.5.2 of RFC5451 for a bit of further explanation should make it clearer, so that's done in the working copy. > Does a signature by this "on behalf of" signer mean something different > from a regular DKIM signature? It appears the current text means the > answer to be yes. Correct, inasmuch as there are some people in the community who think author domain signatures might be more important or valuable than others. This memo doesn't make such an assertion, but merely acknowledges that perception. > It should say this explicitly. If it is not redefining the existing, > core DKIM semantic, it should say so. If it /is/ changing basic DKIM > semantics, then this is more than an "extension" to DKIM. It is not. Section 1 of this draft reiterates that DKIM's core semantics don't extend to any kind of binding of the delivered, validated domain name to any part of the message. However, there are some people who believe that such a binding is valid and useful. This draft is meant for those people, without altering DKIM's base semantics. > I suggest that the incremental semantic should merely be that the > signature by an authorized signer should be interpreted as if the > signature had been by the authorizing domain. > > It's a simple semantic and is, frankly, what I think is intended, based > on the discussions surrounding this mechanism that I've heard. This is stated in Sections 5 and 6. > > In plain English, this reads as an update of ADSP but this draft does not update > > RFC 5617. > > +1 The definition used for "Updates", as I understand it, is that we say "X updates Y" if someone implementing X really needs also to read Y in order to implement X completely. I don't think that's true here. In this case, RFC5617 stands on its own just fine without this addition. If I should be using some other criteria for doing the "Updates", please let me know. > > The IANA Considerations section is unusual. If no action is required at this > > time, the sub-sections are not needed. I suggest updating the "DKIM- Signature > > Tag Specification Registry" for the tags as they will appear on the Internet. > > +1 The working copy already has this change; specifically, Section 8.1 is still the template for a future registry creation, but the remaining subsections are now actionable by IANA. -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf