One document matched: draft-newton-et-al-weirds-rir-query-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="true"?>
<rfc category="std" docName="draft-newton-et-al-weirds-rir-query-00" ipr="trust200902">
<front>
<title abbrev="Uniform RESTful RIR URLs">A Uniform RESTful URL Query Pattern for RIRs</title>
<author fullname="Andrew Lee Newton" initials="A.L." surname="Newton">
<organization abbrev="ARIN">American Registry for Internet Numbers</organization>
<address>
<postal>
<street>3635 Concorde Parkway</street>
<city>Chantilly</city>
<region>VA</region>
<country>US</country>
<code>20151</code>
</postal>
<email>andy@arin.net</email>
<uri>http://www.arin.net</uri>
</address>
</author>
<author fullname="Kaveh Ranjbar" initials="K" surname="Ranjbar">
<organization abbrev="RIPE NCC">RIPE Network Coordination Centre</organization>
<address>
<postal>
<street>Singel 258</street>
<city>Amsterdam</city>
<country>NL</country>
<code>1016AB</code>
</postal>
<email>kranjbar@ripe.net</email>
<uri>http://www.ripe.net</uri>
</address>
</author>
<author fullname="Arturo L. Servin" initials="A.L." surname="Servin">
<organization abbrev="LACNIC">Latin American and Caribbean Internet Address Registry</organization>
<address>
<postal>
<street>Rambla Republica de Mexico 6125</street>
<city>Montevideo</city>
<country>UY</country>
<code>11300</code>
</postal>
<email>aservin@lacnic.net</email>
<uri>http://www.lacnic.net</uri>
</address>
</author>
<date/>
<abstract>
<t>
This document describes uniform patterns for which to construct HTTP URLs
that may be used to retreive information from Regional Internet Registries (RIRs)
using "RESTful" web access patterns.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The Regional Internet Registries (RIRs) have begun experimenting with RESTful web services
for access to Whois data. This document presents uniform patterns which may be
used to contruct URLs for accessing data from these RESTful web services.
</t>
<t>
The patterns described in this document purposefully do not encompass all of the
methods employed in the Whois and RESTful web services of all of the RIRs. The
intent of the patterns described here are to enable lookups of networks by
IP address, autonomous system numbers by number, and reverse DNS meta-data
reverse DNS domain labels. It is envisioned that each RIR
will continue to maintain NICNAME/WHOIS and/or RESTful web services specific to
their needs and those of their constituencies, and the information retreived
through the patterns described here may reference such services.
</t>
<t>
Whois services, in general, are read-only services. Therefore URL patterns
presented here are only applicable to the HTTP GET and HEAD methods.
</t>
<t>
This document does not describe the results or entities returned from issuing
the described URLs with an HTTP GET. It is envisioned that other documents will
describe these entities in various serialization formats, such as XML and JSON.
</t>
<t>
Additionally, resource management, provisioning and update functions are out of
scope for this document. RIRs have various and divergent methods covering these
functions, and it is unlikely a uniform approach for these functions will ever
be possible.
</t>
<t>
And while HTTP contains mechanisms for servers to authenticate clients and
clients to authenticate servers, from which authorization schemes may be built,
both authentication of clients and servers and authorization for access to data
are out-of-scope of this document. In general, these matters require "policy"
and are not the domain of technical standards body.
</t>
</section>
<section title="Path Specification">
<t>
The uniform patterns start with a base URL specified by each RIR or any other
service provider offering this service. The base URL will be appended with
resource type specific path segments. The base URL may contain its own
path segments (e.g. http://example.com/... or http://example.com/restful-whois/... ).
</t>
<t>
The resource type path segments are:
<list style="hanging">
<t hangText="'ip'">IP networks and associated data referenced using either an
IPv4 or IPv6 address (i.e. not CIDR notation).</t>
<t hangText="'autnum'">Autonomous system registrations and associated data referenced
using an AS Plain autonomous system number.</t>
<t hangText="'rdns'">Reverse DNS information and associated data referenced
using a fully-qualified domain name.</t>
</list>
</t>
<section title="IP Networks" anchor="ip-network-paths">
<t>
Queries for information about IP networks are of the form /ip/XXX.XXX.XXX.XXX/...
where the path segment following 'ip' is either an IPv4 or IPv6 address. While an IP address
may fall into multiple IP networks in a hierarchy of networks, this query targets the
"most-specific" or lowest IP network in a hierarchy.
</t>
<t>
Path segments following the IP address target specific information associated with the
targetted IP network in the following way:
<list style="hanging">
<t hangText="'registration'">The query is for the network registration data.</t>
<t hangText="'operator'">The query is for data about the network operator of the IP
network. The network operator is not always considered to be the end user or end
site customer of the IP network, a distinction made in some cases. For example,
a residential Internet installation may be assigned IP addresses, but the provider
from whom they receive Internet access is considered the network operator. Another
rule of thumb is that the network operator is the entity contacted to coordinate
network issues and has published contact information for this purpose, and operator
information can be further decomposed into operator contact information, which
is returned with the 'operator' query when not specifically targetted (see below).</t>
</list>
</t>
<t>
When no path segment follows the IP address, the semantics of the query are that
both registration and operator information are to be returned.
</t>
<figure>
<preamble>The following example URL is a query for the IP network registrion information.</preamble>
<artwork>
http://example.com/somepath/ip/192.0.2.0/registration
</artwork>
</figure>
<figure>
<preamble>The following example URL is a query for the network operator information of
the most specific network containing 192.0.2.0</preamble>
<artwork>
http://example.com/somepath/ip/192.0.2.0/operator
</artwork>
</figure>
<figure>
<preamble>And this is an example URL for both the registration and operator information of
the most specific network containing 192.0.2.0</preamble>
<artwork>
http://example.com/somepath/ip/192.0.2.0
</artwork>
</figure>
<t>
The contact information of an operator maybe specifically targetted by following it with
a 'contacts' path segment. And the type of contact information may be further targetted
by following that path segment with a type. The types are:
<list style="symbols">
<t>tech</t>
<t>admin</t>
<t>abuse</t>
<t>noc</t>
</list>
</t>
<figure>
<preamble>For example:</preamble>
<artwork>
/ip/192.0.2.0/operator/contacts
</artwork>
<postamble>returns all the contact information for the network operator of the
most specific network containing IP address 192.0.2.0.</postamble>
</figure>
<figure>
<preamble>And this path targets only the abuse contacts of that network operator.</preamble>
<artwork>
/ip/192.0.2.0/operator/contacts/abuse
</artwork>
</figure>
</section>
<section title="Autonomous Systems">
<t>
Queries for information regarding autonomous system number registrations are of the form
/autnum/XXX/... where XXX is an autonomous system number. In some registries,
registration of autonomous system numbers is done on an individual number basis, while
other registries may register blocks of autonomous system numbers. The semantics of this
query is such that if a number falls within a range of registered blocks, the target of
the query is the block registration, and that individual number registrations are considered
a block of numbers with a size of 1.
</t>
<figure>
<preamble>For example, to find information on autonomous system number 65551, the
following path would be used:</preamble>
<artwork>
/autnum/65551
</artwork>
</figure>
<t>
The autnum path segment may be followed by a 'registration' or 'operator' path segment or
no additional path segment, all of which follow the semantics
<xref target="ip-network-paths">above</xref>.
</t>
</section>
<section title="Reverse DNS">
<t>
Queries for reverse DNS information are of the form /rdns/XXXXXXXXX/... where
XXXX is a fully-qualified domain name in either the in-addr.arpa or ip6.arpa zones.
</t>
<figure>
<preamble>For example, to find information on the zone serving the network 192.0.2/24,
the following path would be used:</preamble>
<artwork>
/rdns/2.0.192.in-addr.arpa
</artwork>
</figure>
<t>
The rdns path segment may be follwed by a 'registration' or 'operator' path segment or
no additional path segment, all of which follow the semantics in <xref target="ip-network-paths"></xref>.
</t>
</section>
</section>
<section title="Response Formats">
<t>
URLs may contain the 'format' query parameter. The value of the query parameter
contains the MIME type of the desired format of the response. This parameter is used
instead of the HTTP Accept header to defeat web caches and better support HTTP
clients that do not support alteration of the Accept header.
</t>
<figure>
<preamble>The following is an example of a URL for AS 65551 requesting the response
be in text/plain format:</preamble>
<artwork>
http://example.com/autnum/65551?format=text%2Fplain
</artwork>
</figure>
<t>
This document does not specify the contents of the responses. It is envisioned that
multiple format types may be supported. Other documents will specify the contents
of responses.
</t>
</section>
</middle>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-20 12:47:54 |