I suppose it's par for the course that all these substantial changes are
coming in only as I'm trying to hand this stuff off to the area director
and not long ago... ;-)
Michael Thomas wrote:
The current draft breaks out the meaning of the results into a method
specific section. This is an improvement over the previous draft which
didn't discuss them at all, but shoe-horning the global set of results
into method specific results seems rather contrived and arbitrary.
I don't think it's either. Having a fixed set of results makes writing
and extending parsers easy. It's easier in my experience to have the
parser still return one of a fixed set (or a subset of a fixed set) of
results and then have the thing using the parser decide what to do with
those values. Parsers don't care about meaning, only syntax. If a new
method comes along and uses a result keyword that's not in the list of
ones we're supporting, a module using the parser has to wait for the
parser to get updated. When those two modules aren't the same, it can
get annoying to extend the system as a whole.
[mat: i've removed the "acceptable" parts... i'm not sure what that's
bringing to the table... why should auth res go into the filter's
domain? same goes for other methods, I suspect]
Authentication-Results: lives quite squarely in the filter's domain.
The point of using it is to do complete evaluation of the authentication
method so that the MUA doesn't have to. If the MUA has to re-analyze
signatures to determine if local policy is satisfied, we haven't
accomplished very much.
More on this later. I probably won't get a chance to update the draft
now until I'm enroute to IETF this weekend anyway.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html