Thanks Tony, If there are no objections, we'll forward these to Pasi to take action (i.e. update the errata pages) in one week from now,
Stephen. Tony Hansen wrote: > Here's a description of the errata conclusions that were made at today's > meeting. If anyone disagrees, speak now. > > Tony Hansen > [EMAIL PROTECTED] > > Errata 1383 show g= example with * in middle > > Add to the example list for g= the example of "foo*bar": > > Section 3.6.1 should say: > > g= Granularity of the key (plain-text; OPTIONAL, default is > "*"). .... Wildcarding allows matching for addresses such as > "user+*", "*-offer" or "foo*bar". An empty "g=" value never > matches any addresses. > > Errata 1378 "a=" is required > > I was to check if the messages I captured at the interop last year if > there were any that did not have a= in them. I still have 834 of the > messages I received back then. *All of them have a= in them.* Given > that, here is the conclusion: > > Section 3.3 should remove the sentence saying: > > The rsa-sha256 algorithm is the default if no algorithm is > specified. > > Errata 1532 DomainKeys key record compatibility > > Add a section, probably after 6.1.3, with this text: > > 6.1.4 Compatibility Note for DomainKeys > > The definition given here for the key record is upwardly > compatible with what is used for DomainKeys, with the exception > of the "g=" value. In DomainKeys, a key record empty "g=" value > is equivalent to "g=*", while DKIM treats that value as matching > nothing. The value "g=*" means the same in both DomainKeys and > DKIM. > > DomainKeys deployers are encouraged to at least switch their key > records to using the equivalent "g=*" value, which works > equivalently for both DomainKeys and DKIM. > > A DKIM implementation MAY choose to use the lack of a v= value > at the beginning of the key record as an indicator that the key > record is a DomainKeys key record, and interpret an empty "g=" > value as if it were written "g=*". > > Errata 1596 Ambiguity regarding whitespace and b= value > > Add text "(including all surrounding whitespace)" to the > description of deleting the b= value. > > 3.7. Computing the Message Hashes > > 2. The DKIM-Signature header field that exists (verifying) or > will be inserted (signing) in the message, with the value of the > "b=" tag (including all surrounding whitespace) deleted (i.e., > treated as the empty string), canonicalized using the header > canonicalization algorithm specified in the "c=" tag, and > without a trailing CRLF. > > Fix the ambiguity in the base64string grammar to remove leading > and trailing FWS. Replace the existing base64 production with: > > ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") > base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) > [ [FWS] "=" [ [FWS] "=" ] ] > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
