--- 1/draft-ietf-dkim-rfc4871bis-11.txt	2011-06-15 20:15:44.000000000 +0200
+++ 2/draft-ietf-dkim-rfc4871bis-12.txt	2011-06-15 20:15:44.000000000 +0200
@@ -1,21 +1,21 @@
 
 Network Working Group                                    D. Crocker, Ed.
 Internet-Draft                               Brandenburg InternetWorking
 Obsoletes: 4871, 5672                                     T. Hansen, Ed.
 (if approved)                                          AT&T Laboratories
 Intended status: Standards Track                       M. Kucherawy, Ed.
 Expires: December 17, 2011                                     Cloudmark
                                                            June 15, 2011
 
               DomainKeys Identified Mail (DKIM) Signatures
-                     draft-ietf-dkim-rfc4871bis-11
+                     draft-ietf-dkim-rfc4871bis-12
 
 Abstract
 
    DomainKeys Identified Mail (DKIM) permits a person, role, or
    organization that owns the signing domain to claim some
    responsibility for a message by associating the domain with the
    message.  This can be an author's organization, an operational relay
    or one of their agents.  DKIM separates the question of the identity
    of the signer of the message from the purported author of the
    message.  Assertion of responsibility is validated through a
@@ -539,21 +539,21 @@
       below (as "tag-value") only includes 7-bit characters, an
       implementation that wished to anticipate future standards would be
       advised not to preclude the use of UTF8-encoded text in tag=value
       lists.
 
       Formally, the ABNF syntax rules are as follows:
    tag-list  =  tag-spec 0*( ";" tag-spec ) [ ";" ]
    tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
    tag-name  =  ALPHA 0*ALNUMPUNC
    tag-value =  [ tval 0*( 1*(WSP / FWS) tval ) ]
-                     ; WSP and FWS prohibited at beginning and end
+                     ; Prohibits WSP and FWS at beginning and end
    tval      =  1*VALCHAR
    VALCHAR   =  %x21-3A / %x3C-7E
                      ; EXCLAMATION to TILDE except SEMICOLON
    ALNUMPUNC =  ALPHA / DIGIT / "_"
 
    Note that WSP is allowed anywhere around tags.  In particular, any
    WSP after the "=" and any WSP before the terminating ";" is not part
    of the value; however, WSP inside the value is significant.
 
    Tags MUST be interpreted in a case-sensitive manner.  Values MUST be
@@ -2014,21 +2014,21 @@
 
       INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this
       is to insert the DKIM-Signature header field at the beginning of
       the header block.  In particular, it may be placed before any
       existing Received header fields.  This is consistent with treating
       DKIM-Signature as a trace header field.
 
 6.  Verifier Actions
 
    Since a signer MAY remove or revoke a public key at any time, it is
-   recommended that verification occur in a timely manner.  In many
+   advised that verification occur in a timely manner.  In many
    configurations, the most timely place is during acceptance by the
    border MTA or shortly thereafter.  In particular, deferring
    verification until the message is accessed by the end user is
    discouraged.
 
    A border or intermediate MTA MAY verify the message signature(s).  An
    MTA who has performed verification MAY communicate the result of that
    verification by adding a verification header field to incoming
    messages.  This considerably simplifies things for the user, who can
    now use an existing mail user agent.  Most MUAs have the ability to