draft-ietf-weirds-rdap-query-11.txt   draft-ietf-weirds-rdap-query-12.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track S. Hollenbeck Intended status: Standards Track S. Hollenbeck
Expires: January 30, 2015 Verisign Labs Expires: February 19, 2015 Verisign Labs
July 29, 2014 August 18, 2014
Registration Data Access Protocol Query Format Registration Data Access Protocol Query Format
draft-ietf-weirds-rdap-query-11 draft-ietf-weirds-rdap-query-12
Abstract Abstract
This document describes uniform patterns to construct HTTP URLs that This document describes uniform patterns to construct HTTP URLs that
may be used to retrieve registration information from registries may be used to retrieve registration information from registries
(including both Regional Internet Registries (RIRs) and Domain Name (including both Regional Internet Registries (RIRs) and Domain Name
Registries (DNRs)) using "RESTful" web access patterns. Registries (DNRs)) using "RESTful" web access patterns.
Normative Reference Note
Normative references to RFC 7231 and draft-ietf-httpbis-http2 can be
replaced with a reference to RFC 2616 if draft-ietf-httpbis-http2 is
still a work in progress when this document is ready for publication.
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 January 30, 2015. This Internet-Draft will expire on February 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 17 skipping to change at page 2, line 11
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 Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . 2 1. Conventions Used in This Document . . . . . . . . . . . . . . 2
1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 2 1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Path Segment Specification . . . . . . . . . . . . . . . . . 4 3. Path Segment Specification . . . . . . . . . . . . . . . . . 4
3.1. Lookup Path Segment Specification . . . . . . . . . . . . 5 3.1. Lookup Path Segment Specification . . . . . . . . . . . . 4
3.1.1. IP Network Path Segment Specification . . . . . . . . 5 3.1.1. IP Network Path Segment Specification . . . . . . . . 5
3.1.2. Autonomous System Path Segment Specification . . . . 6 3.1.2. Autonomous System Path Segment Specification . . . . 6
3.1.3. Domain Path Segment Specification . . . . . . . . . . 6 3.1.3. Domain Path Segment Specification . . . . . . . . . . 6
3.1.4. Name Server Path Segment Specification . . . . . . . 7 3.1.4. Name Server Path Segment Specification . . . . . . . 7
3.1.5. Entity Path Segment Specification . . . . . . . . . . 8 3.1.5. Entity Path Segment Specification . . . . . . . . . . 7
3.1.6. Help Path Segment Specification . . . . . . . . . . . 8 3.1.6. Help Path Segment Specification . . . . . . . . . . . 8
3.2. Search Path Segment Specification . . . . . . . . . . . . 8 3.2. Search Path Segment Specification . . . . . . . . . . . . 8
3.2.1. Domain Search . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Domain Search . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Name Server Search . . . . . . . . . . . . . . . . . 9 3.2.2. Name Server Search . . . . . . . . . . . . . . . . . 10
3.2.3. Entity Search . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Entity Search . . . . . . . . . . . . . . . . . . . . 10
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 10 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 11
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Internationalization Considerations . . . . . . . . . . . . . 13 6. Internationalization Considerations . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Conventions Used in This Document 1. Conventions Used in This Document
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].
1.1. Acronyms and Abbreviations 1.1. Acronyms and Abbreviations
IDN: Internationalized Domain Name IDN: Internationalized Domain Name
skipping to change at page 3, line 17 skipping to change at page 3, line 10
was first described in a doctoral dissertation [REST]. was first described in a doctoral dissertation [REST].
RESTful: An adjective that describes a service using HTTP and the RESTful: An adjective that describes a service using HTTP and the
principles of REST. principles of REST.
RIR: Regional Internet Registry RIR: Regional Internet Registry
2. Introduction 2. Introduction
This document describes a specification for querying registration This document describes a specification for querying registration
data using a RESTful web service and uniform query patterns. The data using a RESTful web service and uniform query patterns. The
service is implemented using the Hypertext Transfer Protocol (HTTP) service is implemented using the Hypertext Transfer Protocol (HTTP)
[I-D.ietf-httpbis-http2]. [RFC7230].
The protocol described in this specification is intended to address The protocol described in this specification is intended to address
deficiencies with the WHOIS protocol [RFC3912] that have been deficiencies with the WHOIS protocol [RFC3912] that have been
identified over time, including: identified over time, including:
o Lack of standardized command structures, o Lack of standardized command structures,
o lack of standardized output and error structures, o lack of standardized output and error structures,
o lack of support for internationalization and localization, and o lack of support for internationalization and localization, and
o lack of support for user identification, authentication, and o lack of support for user identification, authentication, and
access control. access control.
skipping to change at page 6, line 50 skipping to change at page 6, line 41
Syntax: domain/<domain name> Syntax: domain/<domain name>
Queries for domain information are of the form /domain/XXXX/..., Queries for domain information are of the form /domain/XXXX/...,
where XXXX is a fully-qualified (relative to the root) domain name where XXXX is a fully-qualified (relative to the root) domain name
[RFC1594] in either the in-addr.arpa or ip6.arpa zones (for RIRs) or [RFC1594] in either the in-addr.arpa or ip6.arpa zones (for RIRs) or
a fully-qualified domain name in a zone administered by the server a fully-qualified domain name in a zone administered by the server
operator (for DNRs). Internationalized domain names represented in operator (for DNRs). Internationalized domain names represented in
either A-label or U-label format [RFC5890] are also valid domain either A-label or U-label format [RFC5890] are also valid domain
names. IDNs SHOULD NOT be represented as a mixture of A-labels and names. IDNs SHOULD NOT be represented as a mixture of A-labels and
U-labels; that is, any IDN SHOULD use only A-labels or only U-labels. U-labels; that is, all internationalized labels in an IDN SHOULD be
either A-labels or U-labels.
If the client sends the server an IDN in U-label format, servers that If the client sends the server an IDN in U-label format, servers that
support IDNs MUST convert the IDN into A-label format and perform support IDNs MUST convert the IDN into A-label format and perform
IDNA processing as specified in RFC 5891 [RFC5891]. The server IDNA processing as specified in RFC 5891 [RFC5891]. The server
should perform an exact match lookup using the A-label. should perform an exact match lookup using the A-label.
The following URL would be used to find information describing the The following URL would be used to find information describing the
zone serving the network 192.0.2/24: zone serving the network 192.0.2/24:
http://example.com/rdap/domain/2.0.192.in-addr.arpa http://example.com/rdap/domain/2.0.192.in-addr.arpa
skipping to change at page 7, line 37 skipping to change at page 7, line 26
http://example.com/rdap/domain/xn--fo-5ja.example http://example.com/rdap/domain/xn--fo-5ja.example
3.1.4. Name Server Path Segment Specification 3.1.4. Name Server Path Segment Specification
Syntax: nameserver/<name server name> Syntax: nameserver/<name server name>
The <name server name> parameter represents a fully qualified name as The <name server name> parameter represents a fully qualified name as
specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123]. specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123].
Internationalized names represented in either A-label or U-label Internationalized names represented in either A-label or U-label
format [RFC5890] are also valid name server names. IDN labels SHOULD format [RFC5890] are also valid name server names. IDNs SHOULD NOT
NOT be represented as a mixture of A-labels and U-labels. be represented as a mixture of A-labels and U-labels; that is, all
internationalized labels in an IDN SHOULD be either A-labels or
U-labels.
If the client sends the server an IDN in U-label format, servers that If the client sends the server an IDN in U-label format, servers that
support IDNs MUST convert the IDN into A-label format and perform support IDNs MUST convert the IDN into A-label format and perform
IDNA processing as specified in RFC 5891 [RFC5891]. The server IDNA processing as specified in RFC 5891 [RFC5891]. The server
should perform an exact match lookup using the A-label. should perform an exact match lookup using the A-label.
The following URL would be used to find information for the The following URL would be used to find information for the
ns1.example.com name server: ns1.example.com name server:
http://example.com/rdap/nameserver/ns1.example.com http://example.com/rdap/nameserver/ns1.example.com
skipping to change at page 9, line 11 skipping to change at page 8, line 51
mark character ('?', ASCII value 0x003F), the JSON object value mark character ('?', ASCII value 0x003F), the JSON object value
associated with the object being searched for, the equal sign associated with the object being searched for, the equal sign
character ('=', ASCII value 0x003D), and the search pattern. For the character ('=', ASCII value 0x003D), and the search pattern. For the
domain and entity objects described in this document the plural domain and entity objects described in this document the plural
object forms are "domains" and "entities". object forms are "domains" and "entities".
3.2.1. Domain Search 3.2.1. Domain Search
Syntax: domains?name=<domain search pattern> Syntax: domains?name=<domain search pattern>
Searches for domain information are of the form Syntax: domains?nsLdhName=<domain search pattern>
Syntax: domains?nsIp=<domain search pattern>
Searches for domain information by name are specified using this
form:
/domains?name=XXXX /domains?name=XXXX
where XXXX is a search pattern representing a domain name in XXXX is a search pattern representing a domain name in "letters,
"letters, digits, hyphen" format [RFC5890] in a zone administered by digits, hyphen" format [RFC5890] in a zone administered by the server
the server operator of a DNR. The following URL would be used to operator of a DNR. The following URL would be used to find DNR
find DNR information for domain names matching the "example*.com" information for domain names matching the "example*.com" pattern:
pattern:
http://example.com/rdap/domains?name=example*.com http://example.com/rdap/domains?name=example*.com
Internationalized Domain Names (IDNs) in U-label format [RFC5890] can Internationalized Domain Names (IDNs) in U-label format [RFC5890] can
also be used as search patterns (see Section 4). Searches for these also be used as search patterns (see Section 4). Searches for these
names are of the form /domains?name=XXXX, where XXXX is a search names are of the form /domains?name=XXXX, where XXXX is a search
pattern representing a domain name in U-label format [RFC5890]. pattern representing a domain name in U-label format [RFC5890].
Searches for domain information by name server name are specified
using this form:
/domains?nsLdhName=YYYY
YYYY is a search pattern representing a host name in "letters,
digits, hyphen" format [RFC5890] in a zone administered by the server
operator of a DNR. The following URL would be used to search for
domains delegated to name servers matching the "ns1.example*.com"
pattern:
http://example.com/rdap/domains?nsLdhName=ns1.example*.com
Searches for domain information by name server IP address are
specified using this form:
/domains?nsIp=ZZZZ
ZZZZ is a search pattern representing an IPv4 [RFC1166] or IPv6
[RFC5952] address. The following URL would be used to search for
domains that have been delegated to name servers that resolve to the
"192.0.2.0" address:
http://example.com/rdap/domains?nsIp=192.0.2.0
3.2.2. Name Server Search 3.2.2. Name Server Search
Syntax: nameservers?name=<nameserver search pattern> Syntax: nameservers?name=<name server search pattern>
Searches for name server information can take one of two forms: Syntax: nameservers?ip=<name server search pattern>
/nameservers?name=XXXX Searches for name server information by name server name are
specified using this form:
/nameservers?ip=YYYY /nameservers?name=XXXX
XXXX is a search pattern representing a host name in "letters, XXXX is a search pattern representing a host name in "letters,
digits, hyphen" format [RFC5890] in a zone administered by the server digits, hyphen" format [RFC5890] in a zone administered by the server
operator of a DNR. The following URL would be used to find DNR operator of a DNR. The following URL would be used to find DNR
information for name server names matching the "ns1.example*.com" information for name server names matching the "ns1.example*.com"
pattern: pattern:
http://example.com/rdap/nameservers?name=ns1.example*.com http://example.com/rdap/nameservers?name=ns1.example*.com
Internationalized name server names in U-label format [RFC5890] can
also be used as search patterns (see Section 4). Searches for these
names are of the form /nameservers?name=XXXX, where XXXX is a search
pattern representing a name server name in U-label format [RFC5890].
Searches for name server information by name server IP address are
specified using this form:
/nameservers?ip=YYYY
YYYY is a search pattern representing an IPv4 [RFC1166] or IPv6 YYYY is a search pattern representing an IPv4 [RFC1166] or IPv6
[RFC5952] address. The following URL would be used to search for [RFC5952] address. The following URL would be used to search for
name server names that resolve to the "192.0.2.0" address: name server names that resolve to the "192.0.2.0" address:
http://example.com/rdap/nameservers?ip=192.0.2.0 http://example.com/rdap/nameservers?ip=192.0.2.0
Internationalized name server names in U-label format [RFC5890] can
also be used as search patterns (see Section 4). Searches for these
names are of the form /nameservers?name=XXXX, where XXXX is a search
pattern representing a name server name in U-label format [RFC5890].
3.2.3. Entity Search 3.2.3. Entity Search
Syntax: entities?fn=<entity name search pattern> Syntax: entities?fn=<entity name search pattern>
Syntax: entities?handle=<entity handle search pattern> Syntax: entities?handle=<entity handle search pattern>
Searches for entity information by name are of the form Searches for entity information by name are specified using this
form:
/entities?fn=XXXX /entities?fn=XXXX
where XXXX is a search pattern representing an entity name as where XXXX is a search pattern representing an entity name as
specified in Section 6.1 of [I-D.ietf-weirds-json-response]. The specified in Section 6.1 of [I-D.ietf-weirds-json-response]. The
following URL would be used to find information for entity names following URL would be used to find information for entity names
matching the "Bobby Joe*" pattern. matching the "Bobby Joe*" pattern.
http://example.com/rdap/entities?fn=Bobby%20Joe* http://example.com/rdap/entities?fn=Bobby%20Joe*
Searches for entity information by handle are of the form Searches for entity information by handle are specified using this
form:
/entities?handle=XXXX /entities?handle=XXXX
where XXXX is a search pattern representing an entity handle as where XXXX is a search pattern representing an entity handle as
specified in Section 6.1 of [I-D.ietf-weirds-json-response]. The specified in Section 6.1 of [I-D.ietf-weirds-json-response]. The
following URL would be used to find information for entity names following URL would be used to find information for entity names
matching the "CID-40*" pattern. matching the "CID-40*" pattern.
http://example.com/rdap/entities?handle=CID-40* http://example.com/rdap/entities?handle=CID-40*
skipping to change at page 14, line 32 skipping to change at page 15, line 18
The authors would like to acknowledge the following individuals for The authors would like to acknowledge the following individuals for
their contributions to this document: Francisco Arias, Marc Blanchet, their contributions to this document: Francisco Arias, Marc Blanchet,
Ernie Dainow, Jean-Philippe Dionne, Behnam Esfahbod, John Klensin, Ernie Dainow, Jean-Philippe Dionne, Behnam Esfahbod, John Klensin,
Edward Lewis, John Levine, Mark Nottingham, and Andrew Sullivan. Edward Lewis, John Levine, Mark Nottingham, and Andrew Sullivan.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-13 (work in
progress), June 2014.
[I-D.ietf-weirds-bootstrap] [I-D.ietf-weirds-bootstrap]
Blanchet, M. and G. Leclanche, "Finding the Authoritative Blanchet, M. and G. Leclanche, "Finding the Authoritative
Registration Data (RDAP) Service", draft-ietf-weirds- Registration Data (RDAP) Service", draft-ietf-weirds-
bootstrap-04 (work in progress), July 2014. bootstrap-04 (work in progress), July 2014.
[I-D.ietf-weirds-json-response] [I-D.ietf-weirds-json-response]
Newton, A. and S. Hollenbeck, "JSON Responses for the Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-json-response-07 (work in progress), April 2014. weirds-json-response-08 (work in progress), August 2014.
[I-D.ietf-weirds-rdap-sec] [I-D.ietf-weirds-rdap-sec]
Hollenbeck, S. and N. Kong, "Security Services for the Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol", draft-ietf-weirds- Registration Data Access Protocol", draft-ietf-weirds-
rdap-sec-06 (work in progress), February 2014. rdap-sec-07 (work in progress), August 2014.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-using-http-08 (work in progress), February 2014. weirds-using-http-09 (work in progress), August 2014.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985. host table specification", RFC 952, October 1985.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
skipping to change at page 16, line 15 skipping to change at page 16, line 42
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[Unicode-UAX15] [Unicode-UAX15]
The Unicode Consortium, "Unicode Standard Annex #15: The Unicode Consortium, "Unicode Standard Annex #15:
Unicode Normalization Forms", September 2013, Unicode Normalization Forms", September 2013,
<http://www.unicode.org/reports/tr15/>. <http://www.unicode.org/reports/tr15/>.
10.2. Informative References 10.2. Informative References
skipping to change at page 17, line 42 skipping to change at page 18, line 25
processing text and added search privacy consideration. processing text and added search privacy consideration.
Synchronized examples with response draft. Synchronized examples with response draft.
-09: More search processing and URI prefix updates. Updated fully- -09: More search processing and URI prefix updates. Updated fully-
qualified domain name reference. qualified domain name reference.
-10: Added name server search by IP address. -10: Added name server search by IP address.
-11: Replaced reference to RFC 4627 with reference to RFC 7159. -11: Replaced reference to RFC 4627 with reference to RFC 7159.
Replaced .well-known with bootstrap-defined prefix. Replaced Replaced .well-known with bootstrap-defined prefix. Replaced
references to RFC 2616 with references to RFC 7231 and draft-ietf- references to RFC 2616 with references to RFC 7231 and draft-ietf-
httpbis-http2, adding a note to make it clear that 2616 is an httpbis-http2, adding a note to make it clear that 2616 is an
acceptable reference if http2 isn't ready when needed. acceptable reference if http2 isn't ready when needed.
-12: IDN label processing clarification. Added domain search by
name server name and name server IP address. Minor text editing
for consistency in the search sections. Replaced reference to
draft-ietf-httpbis-http2 with a reference to RFC 7230 and removed
reference note.
Authors' Addresses 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
 End of changes. 30 change blocks. 
51 lines changed or deleted 89 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/