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...)
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
Domain-based identification roughly equates to organizational, not personal,
actors. Although the document appears to define the term Author precisely and
use it consistently within the document, the particular label that's been chosen
is likely to encourage confusion with the reader who will think that "author"
means the /person/ that wrote the message.
Alternative terms to consider:
Author Domain
Organization
Administrative Domain (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.
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.
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.
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.
In Section 6:
"A Verifier implementing both ADSP and ATPS SHOULD treat a message for
which the ATPS test described above passes as if it were signed by
the author domain. That is, a pass of ATPS means a pass for ADSP."
In plain English, this reads as an update of ADSP but this draft does not update
RFC 5617.
+1
In Section 8:
"No actions are required by IANA at this time. The following need
only be applied if and when this specification reaches the Standards
Track."
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
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf