Dear RFC Editor, it seems you missed the changes to the table of contents and one of the changes in section 2.5.2. These are included again in the following list, in addition to one last batch of purely editorial changes. Please apply them. Thank you! ######################################################################### # Table of Contents # ######################################################################### OLD: [...] 10.2. SPF-Authorized E-Mail May Be UBE .........................35 [...] 12.2. The Received-SPF Mail Header .............................37 [...] CHANGES: [...] 10.2. SPF-Authorized E-Mail May Contain Other False Identities .35 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-changed [...] 12.2. The Received-SPF Mail Header Field .......................37 ^^^^^^-changed [...] NEW: [...] 10.2. SPF-Authorized E-Mail May Contain Other False Identities .35 [...] 12.2. The Received-SPF Mail Header Field .......................37 [...] REASON: Reflect prior changes in the ToC. ######################################################################### # Section 2.5, 1st paragraph # ######################################################################### OLD: [...] This allows errors to be returned directly to the sending server by way of SMTP replies. CHANGES: [...] This allows errors to be returned directly to the sending MTA by way of SMTP replies. ^^^-changed NEW: [...] This allows errors to be returned directly to the sending MTA by way of SMTP replies. REASON: Correct terminology to be consistent with the rest of the document. ######################################################################### # Section 2.5.2 # ######################################################################### OLD: The domain owner has explicitly stated that it cannot or does not [...] CHANGES: The domain owner has explicitly stated that he cannot or does not ^^-changed [...] NEW: The domain owner has explicitly stated that he cannot or does not [...] REASON: The domain owner is generally a person, not an organization. ######################################################################### # Section 4.5, 3rd paragraph # ######################################################################### OLD: Starting with the set of records that were returned by the lookup, record selection proceeds in three steps: CHANGES: Starting with the set of records that were returned by the lookup, record selection proceeds in two steps: ^^^-changed NEW: Starting with the set of records that were returned by the lookup, record selection proceeds in two steps: REASON: One step was previously deleted (unless the IESG objects to the prior change, in which case this change would be void). ######################################################################### # Section 5.2, 8th paragraph (last one before the table) # ######################################################################### OLD: Whether this mechanism matches, does not match, or throws an error depends on the result of the recursive evaluation of check_host(): CHANGES: Whether this mechanism matches, does not match, or throws an exception changed-^^^^^^^^^ depends on the result of the recursive evaluation of check_host(): NEW: Whether this mechanism matches, does not match, or throws an exception depends on the result of the recursive evaluation of check_host(): REASON: Correct terminology to be consistent with the rest of the document. ######################################################################### # Section 7, 2nd paragraph after the ABNF definitions # ######################################################################### OLD: The following key-value pairs are designed for later machine parsing. SPF clients SHOULD give enough information so that the SPF results can be verified. That is, at least the "client-ip", "helo", and, if the "MAIL FROM" identity was checked, the "envelope-from". CHANGES: The following key-value pairs are designed for later machine parsing. SPF clients SHOULD give enough information so that the SPF results can be verified. That is, at least the "client-ip", "helo", and, if ^^^-removed the "MAIL FROM" identity was checked, the "envelope-from". ^^^-removed NEW: The following key-value pairs are designed for later machine parsing. SPF clients SHOULD give enough information so that the SPF results can be verified. That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from". REASON: Treat the header field keys as grammatically opaque items without articles. ######################################################################### # Section 8.1, ABNF definitions # ######################################################################### OLD: [...] toplabel = ; LDH rule plus additional TLD restrictions [...] NEW: [...] toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) [...] REASON: The "toplabel" definition was changed to a mere reference to RFC 3696 in the first batch of changes because the original ABNF definition was inaccurate and no better definition was available then. This new definition is accurate however. Although the "toplabel" definition in the first batch of changes was part of a change that was marked "may require IESG review", this was due to the other parts of that change, and _this_ change is purely editorial and should be applied regardless of the IESG's review of the other changes. ######################################################################### # Section 12.2, 2nd paragraph # ######################################################################### OLD: [...] Requesting SPF Council review of any proposed changes and additions to this field is recommended. For information about SPF Council see http://www.openspf.org/Council CHANGES: [...] Requesting SPF Council review of any proposed changes and additions to this field is recommended. For information about the added-^^^ SPF Council see http://www.openspf.org/Council NEW: [...] Requesting SPF Council review of any proposed changes and additions to this field is recommended. For information about the SPF Council see http://www.openspf.org/Council REASON: This change was actually included in the first batch of changes but the "added-^^^" marker was poorly aligned and thus misleading. ######################################################################### # Appendix A, ABNF definitions # ######################################################################### OLD: [...] toplabel = ; LDH rule plus additional TLD restrictions, e.g. com [...] NEW: [...] toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) [...] REASON: Reflect the ABNF grammar changes from the document body in the collected ABNF grammar.