Hi Peter, thanks for the review. Comments inline:
On Sun, Jul 7, 2013 at 10:38 PM, Peter Yee <peter@xxxxxxxxxx> wrote:
On Sun, Jul 7, 2013 at 10:38 PM, Peter Yee <peter@xxxxxxxxxx> wrote:
Page 5, 2nd paragraph after bullet item, 1st sentence: change "pre-standards
DomainKeys defined" to "pre-standard DomainKeys-defined".
This doesn't seem to work. The sentence is basically "SPF defined X and DomainKeys defined Y." "defined" is a verb, not an adjective, so I don't think the hyphen is appropriate.
Page 20, 5th full paragraph, 3rd sentence: regarding whether the field can
be "trusted": why would the MUA check the field in any other location than
prior to the top-most trace field? If the location is the source of
trustedness, then the MUA shouldn't be checking it anywhere else, right?
At the time the work on RFC5451 was originally done, here were some implementations of a plugin API that were not able to prepend trace header fields, and could only append them. Moreover, an MUA or other agent might be configured to trust A-R fields added in more than one place (e.g., a trusted filter), so trusting only the top-most one would limit that possibility.
Page 23, 4th paragraph: as the MTA (implied to be an MTA within the ADMD)
is not the end consumer of the information and the MUA might understand a
later version of the header, shouldn't the decision to remove (or
essentially ignore) the header be made by the MUA?
Good point. I'll add a note about this.
Page 32, section 8.6, 3rd sentence: regarding keeping the list "current",
how about using a new RRType in the DNS?
That's certainly one option to solve that problem. However, I'd prefer not to suggest new mechanisms that haven't been deployed yet.
I'll post the rest in a -10 revision after the telechat, or if directed to do so sooner.
Thanks again,
-MSK