-----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