Murray S. Kucherawy wrote:
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... ;-)
Murray, I think you should keep in mind the high likelihood that late
feedback is due to a) the narrow set of people here and b) the even
narrower set of people who've really implemented/digested this. The
object here is to have a solid spec.
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.
Well, I've implemented this and it didn't strike me as particularly onerous.
And you didn't address my main concern that the current results do not
allow for extension. Where does SSP NXDOMAIN get mapped into the
current authentication results? What if we decide we need another result?
I really don't see the point of being parsimonious here; they're just
labels,
and the probability for human confusion due to weird overlays seems really
high.
[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.
I don't think I agree: Authres is *input* into a filter so that the
authenticator
isn't saddled with having to evaluate "acceptability" locally. We
should limit
Authres to *only* be what an authenticator is able to determine, and not
saddle it with additional requirements like determining what "acceptable"
is.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html