Document: draft-kucherawy-sender-auth-header-17.txt
Reviewer: Suresh Krishnan
Review Date: 2-December-2008
IETF LC End Date: 2-December-2008


Summary: This draft is ready for publication as a Proposed Standard but I have some comments.

Meta Comment
============

One thing that was unclear to me was how the MUA would convey the results to the user. e.g. Using the case C.5. in the appendix, what would the user actually see (Success indication/Failure indication/Something else)? Is this field used more as input for filters rather than communicating authentication information to the user? I would have a hard time establishing the authenticity of the sender given that I know nothing about the (relative) strengths of the authentication methods present in the header.

Editorial
=========

* Section 1.1 Point 3.

Replace

"Create an extensible framework for reporting new authentication methods as such emerge;"

with

"Create an extensible framework for reporting new authentication methods as they emerge;"


* Sections 2.4.1 and 2.4.3

s/unlikley/unlikely/

* Section 2.4.5

s/authenicated/authenticated/

* Section 8.1 5

s/compilant/compliant/