draft-ietf-dkim-rfc4871-errata-02.txt   draft-ietf-dkim-rfc4871-errata-03-01dc.txt 
DKIM D. Crocker, Ed. DKIM D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Intended status: Standards Track February 5, 2009 Updates: RFC4871 April 2, 2009
Expires: August 9, 2009 (if approved)
Intended status: Standards Track
Expires: October 4, 2009
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Errata RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
draft-ietf-dkim-rfc4871-errata-02 draft-ietf-dkim-rfc4871-errata-03-01dc
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2009. This Internet-Draft will expire on October 4, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This documents and resolves errata for RFC 4871, DomainKeys This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures.
Identified Mail (DKIM) Signatures. Specifically the document Specifically the document clarifies the nature, roles and
clarifies the nature, roles and relationship of the two DKIM relationship of the two DKIM identifier tag values that are
identifier tag values that are candidates for payload delivery to a candidates for payload delivery to a receiving processing module.
receiving processing module. This Errata entry has been developed The Update is in the style of an Errata entry, albeit a rather long
and approved by the IETF's DKIM working group. one.
Errata Contact Fields
Name: Dave Crocker
Email: dcrocker@bbiw.net
Type
Technical
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 3 2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 3
3. RFC4871 Section 1. Introduction . . . . . . . . . . . . . . . 4 3. RFC4871 Section 1. Introduction . . . . . . . . . . . . . . . 4
4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . . 4 4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . . 4
5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . . 4 5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . . 4
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . . 4 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . . 4
7. RFC4871 Section 2.10 User Agent Identifier (UAID) . . . . . . 5 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) . . . . . 5
8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . . 5 8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . . 5
9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 5 9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 5
10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 6 10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 6
11. RFC4871 Section 3.8. Signing by Parent Domains . . . . . . . 8 11. RFC4871 Section 3.8. Signing by Parent Domains . . . . . . . 9
12. RFC4871 Section 3.9 Relationship Between SDID and UAID . . . . 9 12. RFC4871 Section 3.9 Relationship Between SDID and AUID . . . . 9
13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 10 13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 10
14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 11 14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 11
15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 11 15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 11
16. Security Considerations . . . . . . . . . . . . . . . . . . . 11 16. Security Considerations . . . . . . . . . . . . . . . . . . . 11
17. Normative References . . . . . . . . . . . . . . . . . . . . . 11 17. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
About the purpose for DKIM, [RFC4871] states: About the purpose for DKIM, [RFC4871] states:
The ultimate goal of this framework is to permit a signing domain The ultimate goal of this framework is to permit a signing domain
to assert responsibility for a message, thus protecting message to assert responsibility for a message, thus protecting message
signer identity... signer identity...
skipping to change at page 3, line 38 skipping to change at page 3, line 38
payload delivery. payload delivery.
This currently leaves signers and assessors with the potential for This currently leaves signers and assessors with the potential for
having differing -- and therefore non-interoperable -- having differing -- and therefore non-interoperable --
interpretations of how DKIM operates. interpretations of how DKIM operates.
This erratum resolves this confusion. It defines new labels for the This erratum resolves this confusion. It defines new labels for the
two values, clarifies their nature, and specifies and their two values, clarifies their nature, and specifies and their
relationship. relationship.
NOTE: This Errata document has been developed and approved by the
IETF's DKIM working group. For more information about DKIM and
its IETF working group, see: <http://dkim.org>.
2. RFC 4871 Abstract 2. RFC 4871 Abstract
Original Text: Original Text:
The ultimate goal of this framework is to permit a signing domain The ultimate goal of this framework is to permit a signing domain
to assert responsibility for a message, to assert responsibility for a message,
Corrected Text: Corrected Text:
The ultimate goal of this framework is to permit a person, role or The ultimate goal of this framework is to permit a person, role or
organization that owns the signing domain to assert responsibility organization that owns the signing domain to assert responsibility
for a message, for a message,
3. RFC4871 Section 1. Introduction 3. RFC4871 Section 1. Introduction
Original Text: Original Text:
skipping to change at page 5, line 4 skipping to change at page 4, line 40
Original Text: Original Text:
(None. Additional text.) (None. Additional text.)
Corrected Text: Corrected Text:
A label that refers to an identity. A label that refers to an identity.
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
Original Text: Original Text:
(None. Additional text.) (None. Additional text.)
Corrected Text: Corrected Text:
A single, opaque value that is the mandatory payload output of A single domain name that is the mandatory payload output of DKIM
DKIM and which refers to the identity claiming responsibility for and that refers to the identity claiming responsibility for
the introduction of a message into the mail stream. It is introduction of a message into the mail stream. For DKIM
specified in section 3.5. processing, the name has only basic domain name semantics; any
possible owner-specific semantics is outside the scope of DKIM.
It is specified in section 3.5.
7. RFC4871 Section 2.10 User Agent Identifier (UAID) 7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
Original Text: Original Text:
(None. Additional text.) (None. Additional text.)
Corrected Text: Corrected Text:
A single, opaque value that identifies the user or agent on behalf A single domain name that identifies the agent or user on behalf
of whom the SDID has taken responsibility. It is specified in of whom the SDID has taken responsibility. For DKIM processing,
section 3.5. the domain name portion of the AUID has only basic domain name
semantics; any possible owner-specific semantics is outside the
scope of DKIM. It is specified in section 3.5.
8. RFC4871 Section 2.11 Identity Assessor 8. RFC4871 Section 2.11 Identity Assessor
Original Text: Original Text:
(None. Additional text.) (None. Additional text.)
Corrected Text: Corrected Text:
The name of the module that consumes DKIM's primary payload, the The name of the module that consumes DKIM's mandatory payload, the
responsible Signing Domain Identifier (SDID). It can optionally responsible Signing Domain Identifier (SDID). The module is
consume the User Agent Identifier (UAID) value, if provided to the dedicated to the assessment of the delivered identifier. Other
module. DKIM (and non-DKIM) values can also be delivered to this module as
well as to a more general message evaluation filtering engine.
However this additional activity is outside the scope of the DKIM
signature specification.
9. RFC4871 Section 3.5 The DKIM-Signature Header Field 9. RFC4871 Section 3.5 The DKIM-Signature Header Field
Original Text: Original Text:
d= The domain of the signing entity (plain-text; REQUIRED). This is d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8. requirements for parent domain signing described in Section 3.8.
skipping to change at page 6, line 44 skipping to change at page 6, line 44
that does not meet these requirements, verifiers MUST consider that does not meet these requirements, verifiers MUST consider
the signature invalid. the signature invalid.
Internationalized domain names MUST be encoded as described in Internationalized domain names MUST be encoded as described in
[RFC3490]. [RFC3490].
ABNF: ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain) domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal ; from RFC 2821 Domain, but excluding
address-literal
10. RFC4871 Section 3.5 The DKIM-Signature Header Field 10. RFC4871 Section 3.5 The DKIM-Signature Header Field
Original Text: Original Text:
i= Identity of the user or agent (e.g., a mailing list manager) on i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable; behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@" OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The standard email address where the Local-part MAY be omitted. The
skipping to change at page 7, line 50 skipping to change at page 8, line 4
well established, nor is its vulnerability to subversion by well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the any assurances that might be made by successful use of the
"i=" options. "i=" options.
Corrected Text: Corrected Text:
i= i=
The Agent or User Identifier (AUID) on behalf of which the SDID
The User Agent Identifier (UAID) on behalf of which the SDID is is taking responsibility (dkim-quoted-printable; OPTIONAL,
taking responsibility (dkim-quoted-printable; OPTIONAL, default default is an empty Local-part followed by an "@" followed by
is an empty Local-part followed by an "@" followed by the the domain from the "d=" tag).
domain from the "d=" tag).
The syntax is a standard email address where the Local-part MAY The syntax is a standard email address where the Local-part MAY
be omitted. The domain part of the address MUST be the same be omitted. The domain part of the address MUST be the same
as, or a subdomain of the value of, the "d=" tag. as, or a subdomain of the value of, the "d=" tag.
Internationalized domain names MUST be converted using the Internationalized domain names MUST be converted using the
steps listed in Section 4 of [RFC3490] using the "ToASCII" steps listed in Section 4 of [RFC3490] using the "ToASCII"
function. function.
ABNF: ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name [ Local-part ] "@" domain-name
The UAID is specified as having the same syntax as an email The AUID is specified as having the same syntax as an email
address, but is not required to have the same semantics. address, but is not required to have the same semantics.
Notably, the domain name is not required to be registered in Notably, the domain name is not required to be registered in
the DNS -- so it might not resolve in a query -- and the Local- the DNS -- so it might not resolve in a query -- and the Local-
part MAY be drawn from a namespace that does not contain the part MAY be drawn from a namespace that does not contain the
user's mailbox. The details of the structure and semantics for user's mailbox. The details of the structure and semantics for
the namespace are determined by the Signer. Any knowledge or the namespace are determined by the Signer. Any knowledge or
use of those details by verifiers or assessors is outside the use of those details by verifiers or assessors is outside the
scope of the DKIM Signing specification. The Signer MAY choose scope of the DKIM Signing specification. The Signer MAY choose
to use the same namespace for its UAIDs as its users' email to use the same namespace for its AUIDs as its users' email
addresses, or MAY choose other means of representing its users. addresses, or MAY choose other means of representing its users.
However, the signer SHOULD use the same UAID for each message However, the signer SHOULD use the same AUID for each message
intended to be evaluated as being within the same sphere of intended to be evaluated as being within the same sphere of
responsibility, if it wishes to offer receivers the option of responsibility, if it wishes to offer receivers the option of
using the UAID as a finer grained, stable identifier than the using the AUID as a finer grained, stable identifier than the
SDID. SDID.
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer might verified individual identity. In such cases, the signer might
wish to assert that although it is willing to go as far as wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit to signing for the domain, it is unable or unwilling to commit to
an individual user name within their domain. It can do so by an individual user name within their domain. It can do so by
including the domain part but not the Local-part of the including the domain part but not the Local-part of the
identity. identity.
skipping to change at page 9, line 20 skipping to change at page 9, line 24
validity of the record to exactly the domain of the signing identity. validity of the record to exactly the domain of the signing identity.
If the referenced key record contains the "s" flag as part of the If the referenced key record contains the "s" flag as part of the
"t=" tag, the domain of the signing identity ("i=" flag) MUST be the "t=" tag, the domain of the signing identity ("i=" flag) MUST be the
same as that of the d= domain. If this flag is absent, the domain of same as that of the d= domain. If this flag is absent, the domain of
the signing identity MUST be the same as, or a subdomain of, the d= the signing identity MUST be the same as, or a subdomain of, the d=
domain. domain.
Corrected Text: Corrected Text:
...for example, a key record for the domain example.com can be ...for example, a key record for the domain example.com can be
used to verify messages where the UAID ("i=" tag of the signature) used to verify messages where the AUID ("i=" tag of the signature)
is sub.example.com, or even sub1.sub2.example.com. In order to is sub.example.com, or even sub1.sub2.example.com. In order to
limit the capability of such keys when this is not intended, the limit the capability of such keys when this is not intended, the
"s" flag MAY be set in the "t=" tag of the key record, to "s" flag MAY be set in the "t=" tag of the key record, to
constrain the validity of the domain of the UAID. If the constrain the validity of the domain of the AUID. If the
referenced key record contains the "s" flag as part of the "t=" referenced key record contains the "s" flag as part of the "t="
tag, the domain of the UAID ("i=" flag) MUST be the same as that tag, the domain of the AUID ("i=" flag) MUST be the same as that
of the SDID (d=) domain. If this flag is absent, the domain of of the SDID (d=) domain. If this flag is absent, the domain of
the UAID MUST be the same as, or a subdomain of, the SDID. the AUID MUST be the same as, or a subdomain of, the SDID.
12. RFC4871 Section 3.9 Relationship Between SDID and UAID 12. RFC4871 Section 3.9 Relationship Between SDID and AUID
Original Text: (None. This is an addition.) Original Text: (None. This is an addition.)
Corrected Text: Corrected Text:
DKIM's primary task is to communicate from the Signer to a DKIM's primary task is to communicate from the Signer to a
recipient-side Identity Assessor a single, Signing Domain recipient-side Identity Assessor a single, Signing Domain
Identifier (SDID) that refers to a responsible identity. DKIM MAY Identifier (SDID) that refers to a responsible identity. DKIM MAY
optionally provide a single responsible User Agent Identifier optionally provide a single responsible Agent or User Identifier
(UAID). (AUID).
Hence, DKIM delivers to receive-side Identity Assessors Hence, DKIM's mandatory delivery to a receive-side Identity
responsible Identifiers that are opaque to the assessor. Their Assessor is a single domain name. Within the scope of its use as
sub-structures and particular semantics are not publicly defined DKIM output, the name has only basic domain name semantics; any
and, therefore, cannot be assumed by an Identity Assessor. possible owner-specific semantics is outside the scope of DKIM.
That is, within its role as a DKIM identifier, additional
semantics cannot be assumed by an Identity Assessor.
A receive-side DKIM verifier MUST communicate the Signing Domain A receive-side DKIM verifier MUST communicate the Signing Domain
Identifier (d=) to a consuming Identity Assessor module and MAY Identifier (d=) to a consuming Identity Assessor module and MAY
communicate the User Agent Identifier (i=) if present. communicate the User Agent Identifier (i=) if present.
To the extent that a receiver attempts to intuit any structured To the extent that a receiver attempts to intuit any structured
semantics for either of the identifiers, this is a heuristic semantics for either of the identifiers, this is a heuristic
function that is outside the scope of DKIM's specification and function that is outside the scope of DKIM's specification and
semantics. Hence it is relegated to a higher-level service, such semantics. Hence it is relegated to a higher-level service, such
as a delivery handling filter that integrates a variety of inputs as a delivery handling filter that integrates a variety of inputs
and performs heuristic analysis of them. and performs heuristic analysis of them.
INFORMATIVE DISCUSSION: This document does not require the value INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or UAID to match the identity in any message header of the SDID or AUID to match the identity in any message header
fields. This is considered to be an assessor policy issue. fields. This is considered to be an assessor policy issue.
Constraints between the value of the SDID or UAID and other Constraints between the value of the SDID or AUID and other
identities in other header fields seek to apply basic identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a role authentication into the semantics of trust associated with a role
such as content author. Trust is a broad and complex topic and such as content author. Trust is a broad and complex topic and
trust mechanisms are subject to highly creative attacks. The trust mechanisms are subject to highly creative attacks. The
real-world efficacy of any but the most basic bindings between the real-world efficacy of any but the most basic bindings between the
SDID or UAID and other identities is not well established, nor is SDID or AUID and other identities is not well established, nor is
its vulnerability to subversion by an attacker. Hence reliance on its vulnerability to subversion by an attacker. Hence reliance on
the use of these options should be strictly limited. In the use of these options should be strictly limited. In
particular, it is not at all clear to what extent a typical end- particular, it is not at all clear to what extent a typical end-
user recipient can rely on any assurances that might be made by user recipient can rely on any assurances that might be made by
successful use of the SDID or UAID. successful use of the SDID or AUID.
13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy 13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy
Original Text: Original Text:
It is beyond the scope of this specification to describe what actions It is beyond the scope of this specification to describe what actions
a verifier system should make, but an authenticated email presents an a verifier system should make, but an authenticated email presents an
opportunity to a receiving system that unauthenticated email cannot. opportunity to a receiving system that unauthenticated email cannot.
Specifically, an authenticated email creates a predictable identifier Specifically, an authenticated email creates a predictable identifier
by which other decisions can reliably be managed, such as trust and by which other decisions can reliably be managed, such as trust and
skipping to change at page 11, line 37 skipping to change at page 11, line 41
Original Text: The tendency is to have the MUA highlight the Original Text: The tendency is to have the MUA highlight the
address associated with this signing identity in some way, in an address associated with this signing identity in some way, in an
attempt to show the user the address from which the mail was sent. attempt to show the user the address from which the mail was sent.
Corrected Text: The tendency is to have the MUA highlight the SDID, Corrected Text: The tendency is to have the MUA highlight the SDID,
in an attempt to show the user the identity that is claiming in an attempt to show the user the identity that is claiming
responsibility for the message. responsibility for the message.
16. Security Considerations 16. Security Considerations
This Errata document clarifies core details about DKIM's payload. As This Update clarifies core details about DKIM's payload. As such it
such it affects interoperability, semantic characterization, and the affects interoperability, semantic characterization, and the
expectations for the identifiers carried with a DKIM signature. expectations for the identifiers carried with a DKIM signature.
Clarification of these details is likely to limit misinterpretation Clarification of these details is likely to limit misinterpretation
of DKIM's semantics. Since DKIM is fundamentally a security of DKIM's semantics. Since DKIM is fundamentally a security
protocol, this should improve its security characteristics. protocol, this should improve its security characteristics.
17. Normative References 17. Normative References
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
 End of changes. 34 change blocks. 
74 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/