-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Barry Leiba
Sent: Thursday, July 22, 2010 8:02 AM
To: IETF DKIM WG
Subject: [ietf-dkim] DKIM errata 1532 and 1596
----------- 1532
What Tony says is not consistent with the WG consensus, which was NOT
to REQUIRE the presence of "v=DKIM1", and the text (Tony's "N/A"
notwithstanding) makes it clear that the absence of v= is interpreted
as "v=DKIM1".
He's correct, though, that the intent was for the DKIM key record to
be backward compatible with DK (RFC 4870, Historical), but that the g=
tag screws that up. Perhaps what would be correct to say is this,
added after the g= paragraph and before its ABNF:
Exception: if "g=" is specified with an empty value AND there is NO
"v="
specified at all, implementations MAY interpret this in the context
of
DomainKeys [RFC4870], treating it as DKIM's "g=*".
I like this compromise.
----------- 1596
1596 is trickier and more involved. I think there's too much there to
make it "Verified" as is, and, while it's clear that Tony's right
about clarifying this point, it's not clear that it's been a real
problem for implementations. I think we need more comment from Tony
about it, and then have a brief discussion in the working group.
I concur that there's an ambiguity, but I also agree that it's not urgent.
My vote would be to construct the grammar or include remarks such that the
actual value of "b=", or of any tag's value really, starts at the first
character after "=" and ends at the first ";" or end-of-string, but with all
unquoted unescaped whitespace removed.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html