draft-ietf-weirds-using-http-01.txt   draft-ietf-weirds-using-http-02.txt 
Network Working Group A. Newton Network Working Group A.L. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track B. Ellacott Intended status: Standards Track B.J. Ellacott
Expires: June 8, 2013 APNIC Expires: September 26, 2013 APNIC
N. Kong N. Kong
CNNIC CNNIC
December 5, 2012 March 25, 2013
Using the Registration Data Access Protocol (RDAP) with HTTP Using the Registration Data Access Protocol (RDAP) with HTTP
draft-ietf-weirds-using-http-01 draft-ietf-weirds-using-http-02
Abstract Abstract
This document describes the usage of the Registration Data Access This document describes the usage of the Registration Data Access
Protocol (RDAP) using HTTP. Protocol (RDAP) using HTTP.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 8, 2013. This Internet-Draft will expire on September 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Accept Header . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . . 6
5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . . 7
5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . . 7
5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . . 7
5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Internationalization Considerations . . . . . . . . . . . . . 10
8.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Language Identifiers in Queries and Responses . . . . . . 10
8.3. Language Identifiers in HTTP Headers . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Cache Busting . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document describes the usage of HTTP for Registration Data This document describes the usage of HTTP for Registration Data
Directory Services running on RESTful web servers. The goal of this Directory Services running on RESTful web servers. The goal of this
document is to tie together the usage patterns of HTTP into a common document is to tie together the usage patterns of HTTP into a common
profile applicable to the various types of Directory Services serving profile applicable to the various types of Directory Services serving
Registration Data using RESTful styling. By giving the various Registration Data using RESTful styling. By giving the various
Directory Services common behavior, a single client is better able to Directory Services common behavior, a single client is better able to
retrieve data from Directory Services adhering to this behavior. retrieve data from Directory Services adhering to this behavior.
In designing these common usage patterns, this draft endeavours to In designing these common usage patterns, this draft endeavours to
satisfy requirements for a Registration Data Access Protocol (RDAP) satisfy requirements for a Registration Data Access Protocol (RDAP).
that is documented in [draft-kucherawy-weirds-requirements]. This This draft also introduces an additional design consideration to
draft also introduces an additional design consideration to define a define a simple use of HTTP. Where complexity may reside, it is the
simple use of HTTP. Where complexity may reside, it is the goal of goal of this specification to place it upon the server and to keep
this specification to place it upon the server and to keep the client the client as simple as possible. A client implementation should be
as simple as possible. A client implementation should be possible possible using common operating system scripting tools.
using common operating system scripting tools.
This is the basic usage pattern for this protocol: This is the basic usage pattern for this protocol:
1. A client issues an HTTP query using GET. As an example, a query 1. A client issues an HTTP query using GET. As an example, a query
for the network registration 192.0.2.0 might be for the network registration 192.0.2.0 might be http://
http://example.com/ip/192.0.2.0. example.com/ip/192.0.2.0.
2. If the receiving server has the information for the query, it 2. If the receiving server has the information for the query, it
examines the Accept header field of the query and returns a 200 examines the Accept header field of the query and returns a 200
response with a response entity appropriate for the requested response with a response entity appropriate for the requested
format. format.
3. If the receiving server does not have the information for the 3. If the receiving server does not have the information for the
query but does have knowledge of where the information can be query but does have knowledge of where the information can be
found, it will return a redirection response (3xx) with the found, it will return a redirection response (3xx) with the
Location: header containing an HTTP URL pointing to the Location: header containing an HTTP URL pointing to the
skipping to change at page 4, line 6 skipping to change at page 3, line 4
4. If the receiving server does not have the information being 4. If the receiving server does not have the information being
requested and does not have knowledge of where the information requested and does not have knowledge of where the information
can be found, it should return a 404 response. can be found, it should return a 404 response.
It is important to note that it is not the intent of this document to It is important to note that it is not the intent of this document to
redefine the meaning and semantics of HTTP. The purpose of this redefine the meaning and semantics of HTTP. The purpose of this
document is to clarify the use of standard HTTP mechanisms for this document is to clarify the use of standard HTTP mechanisms for this
application. application.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
As is noted in SSAC Report on WHOIS Terminology and Structure As is noted in SSAC Report on WHOIS Terminology and Structure
[SAC-051], the term "Whois" is overloaded, often referring to a [SAC-051], the term "Whois" is overloaded, often referring to a
protocol, a service and data. In accordance with [SAC-051], this protocol, a service and data. In accordance with [SAC-051], this
document describes the base behavior for a Registration Data Access document describes the base behavior for a Registration Data Access
Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for
Doman Name Registries (DNRs), DNRD-AP. This document and others from Domain Name Registries (DNRs), DNRD-AP. This document and others
the IETF WEIRDS working group describe a single protocol, RDAP, for from the IETF WEIRDS working group describe a single protocol, RDAP,
access to the data of both DNRs and Regional Internet Registries for access to the data of both DNRs and Regional Internet Registries
(RIRs). RIRs are also often referred to as number resource (RIRs). RIRs are also often referred to as number resource
registries and are responsible for the registration of IP address registries and are responsible for the registration of IP address
networks and autonomous system numbers. networks and autonomous system numbers.
3. Design Intents 3. Design Intents
There are a few design criteria this document attempts to support. There are a few design criteria this document attempts to support.
First, each query is meant to return either zero or one result. With First, each query is meant to return either zero or one result. With
the maximum upper bound being set to one, the issuance of redirects the maximum upper bound being set to one, the issuance of redirects
is simplified to the known query/respone model used by HTTP is simplified to the known query/response model used by HTTP
[RFC2616]. Should a result contain more than one result, some of [RFC2616]. Should a result contain more than one result, some of
which are better served by other servers, the redirection model which are better served by other servers, the redirection model
becomes much more complicated. becomes much more complicated.
Second, multiple response formats are supported by this protocol. At Second, multiple response formats are supported by this protocol. At
present the IETF WEIRDS working group is defining only a JSON present the IETF WEIRDS working group is defining only a JSON
[RFC4627] response format, but server operators may use other data [RFC4627] response format, but server operators may use other data
formats when those formats are requested. formats when those formats are requested.
Third, HTTP offers a number of transport protocol mechanisms not Third, HTTP offers a number of transport protocol mechanisms not
skipping to change at page 6, line 6 skipping to change at page 4, line 4
Third, HTTP offers a number of transport protocol mechanisms not Third, HTTP offers a number of transport protocol mechanisms not
described further in this document. Operators are able to make use described further in this document. Operators are able to make use
of these mechanisms according to their local policy, including cache of these mechanisms according to their local policy, including cache
control, authorization, compression, and redirection. HTTP also control, authorization, compression, and redirection. HTTP also
benefits from widespread investment in scalability, reliability, and benefits from widespread investment in scalability, reliability, and
performance, and widespread programmer understanding of client performance, and widespread programmer understanding of client
behaviours for RESTful web services, reducing the cost to deploy behaviours for RESTful web services, reducing the cost to deploy
Registration Data Directory Services and clients. Registration Data Directory Services and clients.
4. Queries 4. Queries
4.1. Accept Header 4.1. Accept Header
Clients SHOULD put the media type of the format they desire in the RDAP clients MUST include an Accept: header specifying application/
Accept header field. rdap+json, application/json, or both. Servers receiving an RDAP
request MUST return an entity with Content-Type application/
Accept: application/rdap rdap+json.
Servers SHOULD respond with an appropriate media type in the Content-
Type header in accordance with the preference rules for the Accept
header in HTTP [RFC2616].
Content-Type: application/rdap
Clients MAY use a generic media type for the desired data format of This specification does not define the responses a server returns to
the response (e.g. "application/json"), but servers SHOULD respond a request with any other media types in the Accept: header, or with
with the most appropriate media type (e.g. "application/rdap"). In no Accept: header. One possibility would be to return a response in
other words, a client may use "application/json" to express that it a media type suitable for rendering in a web browser.
desires JSON or "application/rdap" to express that it desires RDAP
specific JSON, but the server would respond with "application/rdap".
4.2. Query Parameters 4.2. Query Parameters
Servers SHOULD ignore unknown query parameters. Use of unknown query Servers SHOULD ignore unknown query parameters. Use of unknown query
parameters for cache-busting is described in Appendix A. parameters for cache-busting is described in Appendix A.
5. Types of HTTP Response 5. Types of HTTP Response
This section describes the various types of responses a server may This section describes the various types of responses a server may
send to a client. While no standard HTTP response code is forbidden send to a client. While no standard HTTP response code is forbidden
skipping to change at page 7, line 36 skipping to change at page 5, line 4
response code and an HTTP URL in the Location: header. The client is response code and an HTTP URL in the Location: header. The client is
expected to issue a subsequent query using the given URL without any expected to issue a subsequent query using the given URL without any
processing of the URL. In other words, the server is to hand back a processing of the URL. In other words, the server is to hand back a
complete URL and the client should not have to transform the URL to complete URL and the client should not have to transform the URL to
follow it. follow it.
A server SHOULD use a 301 response to inform the client of a A server SHOULD use a 301 response to inform the client of a
permanent move and a 307 response otherwise. For this application, permanent move and a 307 response otherwise. For this application,
such an example of a permanent move might be a top level domain (TLD) such an example of a permanent move might be a top level domain (TLD)
operator informing a client the information being sought can be found operator informing a client the information being sought can be found
with another TLD operator (i.e. a query for the domain bar in with another TLD operator (i.e. a query for the domain bar in
foo.example is found at http://foo.example/domain/bar). foo.example is found at http://foo.example/domain/bar).
In other words, when generating the redirect url, the server will
only alter the base of the URL. It will not attempt to normalize or
modify the path segment.
For example, if the client sends http://serv1.example.com/weirds/
domain/example.com, the server redirecting to https://
serv2.example.net/weirds2/ would set the Location: field to the
value: https://serv2.example.net/weirds2/domain/example.com.
5.3. Negative Answers 5.3. Negative Answers
If a server wishes to respond that it has no information regarding If a server wishes to respond that it has no information regarding
the query, it SHOULD return a 404 response code. Optionally, it MAY the query, it SHOULD return a 404 response code. Optionally, it MAY
include additional information regarding the negative answer in the include additional information regarding the negative answer in the
HTTP entity body. HTTP entity body.
5.4. Malformed Queries 5.4. Malformed Queries
If a server receives a query which it cannot understand, it SHOULD If a server receives a query which it cannot understand, it SHOULD
return a 400 response code. Optionally, it MAY include additional return a 400 response code. Optionally, it MAY include additional
information regarding this negative answer in the HTTP entity body. information regarding this negative answer in the HTTP entity body.
5.5. Rate Limits
Some servers apply rate limits to deter address scraping and other
abuses. When a server declines to answer a query due to rate limits,
it MAY return a 429 response code as described in [RFC6585]. A
client that receives a 429 response SHOULD decrease its query rate,
and honor the Retry-After header if one is present.
Note that this is not a defense against denial-of-service attacks,
since a malicious client could ignore the code and continue to send
queries at a high rate.
6. Extensibility 6. Extensibility
For extensibility purposes, this document defines an IANA registry For extensibility purposes, this document defines an IANA registry
for prefixes used in JSON [RFC4627] data serialization and URI path for prefixes used in JSON [RFC4627] data serialization and URI path
segments (see Section 7). segments (see Section 7).
Prefixes and identifiers SHOULD only consist of the alphabetic ASCII Prefixes and identifiers SHOULD only consist of the alphabetic ASCII
characters A through Z in both uppercase and lowercase, the numerical characters A through Z in both uppercase and lowercase, the numerical
digits 0 through 9, underscore characters, and SHOULD NOT begin with digits 0 through 9, underscore characters, and SHOULD NOT begin with
an underscore character, numerical digit or the characters "xml". an underscore character, numerical digit or the characters "xml".
skipping to change at page 9, line 7 skipping to change at page 6, line 28
This restriction is a union of the Ruby programming language This restriction is a union of the Ruby programming language
identifier syntax and the XML element name syntax and has two identifier syntax and the XML element name syntax and has two
purposes. First, client implementers using modern programming purposes. First, client implementers using modern programming
languages such as Ruby or Java may use libraries that automatically languages such as Ruby or Java may use libraries that automatically
promote JSON names to first order object attributes or members. promote JSON names to first order object attributes or members.
Second, a clean mapping between JSON and XML is easy to accomplish Second, a clean mapping between JSON and XML is easy to accomplish
using these rules. using these rules.
7. IANA Considerations 7. IANA Considerations
7.1. RDAP Extensions Registry
This specification proposes an IANA registry for RDAP extensions. This specification proposes an IANA registry for RDAP extensions.
The purpose of this registry is to ensure uniqueness of extension The purpose of this registry is to ensure uniqueness of extension
identifiers. The extension identifier is used as prefix in JSON identifiers. The extension identifier is used as prefix in JSON
names and as a prefix of path segments in RDAP URLs. names and as a prefix of path segments in RDAP URLs.
The production rule for these identifiers is specified in Section 6. The production rule for these identifiers is specified in Section 6.
In accordance with RFC5226, the IANA policy for assigning new values In accordance with RFC5226, the IANA policy for assigning new values
shall be Specification Required: values and their meanings must be shall be Specification Required: values and their meanings must be
documented in an RFC or in some other permanent and readily available documented in an RFC or in some other permanent and readily available
skipping to change at page 10, line 5 skipping to change at page 7, line 27
Registry operator: The Registry of the Moon, LLC Registry operator: The Registry of the Moon, LLC
Published specification: http://www.example/moon_apis/rdap Published specification: http://www.example/moon_apis/rdap
Person & email address to contact for further information: Person & email address to contact for further information:
Professor Bernardo de la Paz <berny@moon.example> Professor Bernardo de la Paz <berny@moon.example>
Intended usage: COMMON Intended usage: COMMON
7.2. RDAP Media Type Registration
This specification registers the "application/rdap+json" media type.
Type name: application
Subtype name: rdap+json
Required parameters: n/a
Encoding considerations: n/a
Security considerations: n/a
Interoperability considerations: n/a
Published specification: [[ this document ]]
Applications that use this media type: RDAP
Additional information: n/a
Person & email address to contact for further information: Andy
Newton &andy@hxr.us&
Intended usage: COMMON
Restrictions on usage: none
Author: Andy Newton
Change controller: IETF
Provisional Registration: Yes
8. Internationalization Considerations 8. Internationalization Considerations
8.1. URIs and IRIs 8.1. URIs and IRIs
Clients MAY use IRIs as they see fit, but MUST transform them to URIs Clients MAY use IRIs as they see fit, but MUST transform them to URIs
[RFC3986] for interaction with RDAP servers. RDAP servers MUST use [RFC3986] for interaction with RDAP servers. RDAP servers MUST use
URIs in all responses, and clients MAY transform these URIs to IRIs. URIs in all responses, and clients MAY transform these URIs to IRIs.
8.2. Language Identifiers in Queries and Responses 8.2. Language Identifiers in Queries and Responses
skipping to change at page 11, line 5 skipping to change at page 9, line 5
8.3. Language Identifiers in HTTP Headers 8.3. Language Identifiers in HTTP Headers
Given the description of the use of language identifiers in Given the description of the use of language identifiers in
Section 8.2, unless otherwise specified servers SHOULD ignore the Section 8.2, unless otherwise specified servers SHOULD ignore the
HTTP [RFC2616] Accept-Language header when formulating responses. HTTP [RFC2616] Accept-Language header when formulating responses.
However, servers MAY return language identifiers in the Content- However, servers MAY return language identifiers in the Content-
Language header so as to inform clients of the intended language of Language header so as to inform clients of the intended language of
HTTP layer messages. HTTP layer messages.
9. Normative References 9. Contributing Authors and Acknowledgements
[draft-kucherawy-weirds-requirements] John Levine provided text to tighten up the Accept header usage and
Kucherawy, M., "Requirements For Internet Registry the text for the section on 429 responses.
Services", Work in progress: Internet
Drafts draft-kucherawy-weirds-requirements-04.txt, Marc Blanchet provided some clarifying text regarding the use of URLs
April 2011. with redirects.
10. Normative References
[draft-ietf-weirds-json-response] [draft-ietf-weirds-json-response]
Newton, A. and S. Hollenbeck, "JSON Responses for the Newton, A.L. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", Work in Registration Data Access Protocol (RDAP)", Work in
progress: Internet progress: Internet Drafts draft-ietf-weirds-json-
Drafts draft-ietf-weirds-json-response-01.txt, response-01.txt, December 2012.
December 2012.
[SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS
Terminology and Structure", September 2011. Terminology and Structure", September 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012.
Appendix A. Cache Busting Appendix A. Cache Busting
To overcome issues with misbehaving HTTP [RFC2616] cache To overcome issues with misbehaving HTTP [RFC2616] cache
infrastructure, clients MAY use an adhoc and improbably used query infrastructure, clients MAY use an adhoc and improbably used query
parameter with a random value of their choosing. As Section 4.2 parameter with a random value of their choosing. As Section 4.2
instructs servers to ignore unknown parameters, this is unlikely to instructs servers to ignore unknown parameters, this is unlikely to
have any known side effects. have any known side effects.
An example of using an unknown query parameter to bust caches: An example of using an unknown query parameter to bust caches:
skipping to change at page 14, line 5 skipping to change at page 10, line 30
* Simplified media type, removed "level" parameter. * Simplified media type, removed "level" parameter.
* Updated 2119 language and added boilerplate. * Updated 2119 language and added boilerplate.
* In section 1, noted that redirects can go to redirect servers * In section 1, noted that redirects can go to redirect servers
as well. as well.
* Added Section 8.2 and Section 8.3. * Added Section 8.2 and Section 8.3.
Authors' Addresses -02
* Added a section on 429 response codes.
* Changed Accept header language in section 4.1
* Removed reference to the now dead requirements draft.
* Added contributing authors and acknowledgements section.
* Added some clarifying text regarding complete URLs in the
redirect section.
* Changed media type to application/rdap+json
* Added media type registration
Authors' Addresses
Andrew Lee Newton Andrew Lee Newton
American Registry for Internet Numbers American Registry for Internet Numbers
3635 Concorde Parkway 3635 Concorde Parkway
Chantilly, VA 20151 Chantilly, VA 20151
US US
Email: andy@arin.net Email: andy@arin.net
URI: http://www.arin.net URI: http://www.arin.net
Byron J. Ellacott Byron J. Ellacott
 End of changes. 29 change blocks. 
77 lines changed or deleted 119 lines changed or added

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