Two ABNF issues have been brought to my attention regarding
Authentication-Results:
1) The current definition of the "ptype.property=pvalue" construction is
in conflict with the examples. In particular, "pvalue" is defined as:
pvalue = [CFWS] ( token / addr-spec ) [CFWS]
...with "addr-spec" imported from RFC5322. However, "addr-spec" can't
have an empty local-part, so DKIM's "i=" example of "@example.com" as a
"pvalue" isn't permitted by the current ABNF. My proposed solution is to
tweak the ABNF to become:
pvalue = [CFWS] ( token / [ [ local-part ] "@" ] domain-name ) [CFWS]
...with "domain-name" imported from RFC4871 (DKIM). I believe I can do
this during AUTH48.
2) Since "property" is a "token" (from MIME), it can start with a ".".
This allows "header..foo=bar", which at least aesthetically looks like a
bug in the ABNF. The person who brought this to my attention suggests
redefining "propspec" as:
propspec = ptype [CFWS] "/" [CFWS] property [CFWS] "=" pvalue
This seems reasonable to me, but my concern is the number of deployed
implementations out there (mine included) which already implement the
current ABNF and separate "ptype" and "property" on the first "." found.
Such parsers seeing "header..foo=bar" would get the "ptype" as "header"
and the "property" as ".foo" which I contend is correct, so there's
actually no ambiguity. However, I also understand the concern.
Thus, being sensitive to the deployed base out there, my suggestion would
be to leave this as-is and note it in an erratum once the draft publishes
as an RFC for later use in a revision draft.
Opinions on both points are welcome.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html