One document matched: draft-ietf-weirds-using-http-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-ietf-weirds-using-http-00" ipr="trust200902">
<front>
<title abbrev="RDAP over HTTP">
Using the Registration Data Access Protocol (RDAP) with HTTP
</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="Byron J. Ellacott" initials="B.J." surname="Ellacott">
<organization abbrev="APNIC">Asia Pacific Network Information Center</organization>
<address>
<postal>
<street>6 Cordelia Street</street>
<city>South Brisbane</city>
<country>Australia</country>
<code>QLD 4101</code>
</postal>
<email>bje@apnic.net</email>
<uri>http://www.apnic.net</uri>
</address>
</author>
<author initials="N." surname="Kong" fullname="Ning Kong">
<organization abbrev="CNNIC">
China Internet Network Information Center
</organization>
<address>
<postal>
<street>4 South 4th Street, Zhongguancun, Haidian District </street>
<country>China</country>
<code>100190</code> <city>Beijing</city>
</postal>
<phone>+86 10 5881 3147</phone>
<email>nkong@cnnic.cn</email>
</address>
</author>
<date/>
<abstract>
<t> This document describes the usage of the Registration Data Access Protocol (RDAP)
using HTTP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document describes the usage of HTTP for Registration Data Directory Services
running on RESTful web servers. The goal of this document is to tie together the
usage patterns of HTTP into a common profile applicable to the various types of
Directory Services serving Registration Data using RESTful styling. By giving the
various Directory Services common behavior, a single client is better able to
retrieve data from Directory Services adhering to this behavior.
</t>
<t>
In designing these common usage patterns, this draft endeavours to satisfy
requirements for a Registration Data Access Protocol (RDAP) that is documented in
<xref target="draft-kucherawy-weirds-requirements"/>. This draft also introduces an
additional design consideration to define a simple use of HTTP. Where complexity may
reside, it is the goal of this specification to place it upon the server and to keep
the client as simple as possible. A client should be possible using common operating
system scripting tools.
</t>
<t>
This is the basic usage pattern for this protocol:
<list style="numbers">
<t>A client issues an HTTP query using GET. As an example, a query for
the network registration 192.168.0.0 might be http://example.com/ip/192.168.0.0.</t>
<t>If the receiving server has the information for the query, it examines
the Accept header field of the query and returns a 200 response with a response
entity appropriate for the requested format.</t>
<t>If the receiving server does not have the information for the query but does
have knowledge of where the information can be found, it will return a
redirection response (3xx) with the Redirect header containing an HTTP URL pointing
to the information. The client is expected to re-query using that HTTP URL.</t>
<t>If the receiving server does not have the information being requested and
does not have knowledge of where the information can be found, it should
return a 404 response.</t>
</list>
</t>
<t>
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 document is to clarify the use
of standard HTTP mechanisms for this application.
</t>
</section>
<section title="Terminology">
<t>
As is noted in <xref target="SAC-051">SSAC Report on WHOIS Terminology and Structure</xref>,
the term "Whois" is overloaded, often referring to a protocol, a service and data.
In accordance with <xref target="SAC-051"></xref>, this document describes the base
behavior for a Registration Data Access Protocol (RDAP).
<xref target="SAC-051"></xref> describes a protocol profile of RDAP for Doman Name
Registries (DNRs), DNRD-AP. This document and others from the IETF WEIRDS working
group describe a single protocol, RDAP, for access to the data of both DNRs and
Regional Internet Registries (RIRs). RIRs are also often refered to as number resource
registries and are responsible for the registration of IP address networks and
autonomous system numbers.
</t>
</section>
<section title="Design Intents">
<t>
There are a few design criteria this document attempts to support.
</t>
<t>
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 is simplified to the
known query/respone model used by <xref target="RFC2616">HTTP</xref>.
Should a result contain more than one result,
some of which are better served by other servers, the redirection model becomes
much more complicated.
</t>
<t>
Second, multiple response formats are supported by this protocol. This document
outlines the base usage of JSON and XML, but server operators may support other
formats as they desire if appropriate.
</t>
<t> Third, HTTP offers a number of transport protocol mechanisms not described further
in this document. Operators are able to make use of these mechanisms according to
their local policy, including cache control, authorization, compression, and
redirection. HTTP also benefits from widespread investment in scalability,
reliability, and performance, and widespread programmer understanding of client
behaviours for RESTful web services, reducing the cost to deploy Registration Data
Directory Services and clients.
</t>
</section>
<section title="Queries">
<section title="Accept Header" anchor="accept_header">
<t> Clients SHOULD put the media type of the format they desire in
the Accept header field, and SHOULD use the Accept header parameter
"level" to indicate the version of the format acceptable <xref target="RFC2616"></xref>.
</t>
<figure anchor="accept_header_example">
<artwork>
Accept: applicaiton/rdap+json;level=0
</artwork>
</figure>
<t>
Servers SHOULD respond with an appropriate media type
in the Content-Type header in accordance with the preference rules for the Accept
header in <xref target="RFC2616">HTTP</xref>. Servers SHOULD affix
a media type parameter of "level" appropriate to the version of the format
being sent.
</t>
<figure anchor="content_type_header_example">
<artwork>
Content-Type: application/rdap+json;level=0
</artwork>
</figure>
<t>
Clients MAY use a generic media type for the desired data format of the
response (e.g. "application/json"), but servers SHOULD respond with the most
appropriate media type and corresponding level (e.g. "application/rdap+json;level=0").
In other words, a client may use "application/json" to express that it
desires JSON or "application/weirds_blah+json" to express that it
desires WEIRDS BLAH in JSON. The server MUST respond with
"application/rdap+json;level=0".
</t>
</section>
<section title="Query Parameters" anchor="parameters">
<t>
Servers SHOULD ignore unknown query parameters. Use of unknown query
parameters for cache-busting is described in <xref target="cache-busting"></xref>.
</t>
</section>
</section>
<section title="Types of HTTP Response" anchor="http_responses">
<t>
This section describes the various types of responses a server may send to a client.
While no standard HTTP response code is forbidden in usage, at a minimum clients
should understand the response codes described in this section. It is expected that
usage of response codes and types for this application not defined here will be
described in subsequent documents.
</t>
<section title="Positive Answers">
<t>
If a server has the information requested by the client and wishes to respond
to the client with the information according to its policies, it should encode
the answer in the format most appropriate according to the standard and defined
rules for processing the HTTP Accept header, and return that answer in
the body of a 200 response.
</t>
</section>
<section title="Redirects">
<t>
If a server wishes to inform a client that the answer to a given query can be found
elsewhere, it SHOULD return either a 301 or a 307 response code and an HTTP URL in
the Redirect header. The client is 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 complete URL and the client should not have to transform the URL to follow it.
</t>
<t>
A server should use a 301 response to inform the client of a permanent move and a
307 response otherwise. For this application, such an example of a permanent move
might be a TLD operator informing a client the information being sought can be
found with another TLD operator (i.e. a query for the domain bar in foo.example is found
at http://foo.example/domain/bar).
</t>
</section>
<section title="Negative Answers">
<t>
If a server wishes to respond that it has no information regarding the query,
it SHOULD return a 404 response code. Optionally, it may include additional
information regarding the lack of information as defined by
<xref target="common_error_body"/>.
</t>
</section>
<section title="Malformed Queries">
<t>
If a server receives a query which it cannot understand, it SHOULD return
a 400 response code. Optionally, it may include additional information about
why it does not understand the query as defined by <xref target="common_error_body"/>.
</t>
</section>
</section>
<section title="Use of JSON">
<section title="Signaling">
<t>
Clients may signal their desire for JSON using the "application/json" media type
or a more application specific JSON media type.
</t>
</section>
<section title="Naming" anchor="json_naming">
<t> Clients processing <xref target="RFC4627">JSON</xref> responses SHOULD ignore
values associated with unrecognized
names. Servers MAY insert values signified by names into the JSON responses which
are not specified in this document. Insertion of unspecified values into JSON
responses SHOULD have names prefixed with a short identifier followed by an
underscore followed by a meaningful name. </t>
<t> For example, a JSON object may have "handle" and "remarks" formally documented
in a specification. Clients adhering to that specification will have
appropriate knowledge of the meaning of "handle" and "remarks".
</t>
<figure anchor="json_example_no_extra_values">
<preamble>
Consider the following JSON response with JSON names.
</preamble>
<artwork>
{
"handle" : "ABC123",
"remarks" : [
"she sells seas shells",
"down by the seashore"
]
}
</artwork>
</figure>
<t>
If The Registry of the Moon desires to express information not found in
the specification, it might select "lunarNic" as its identifying prefix and insert,
as an example, the name "lunarNic_beforeOneSmallStep" to signify registrations
occuring before the first moon landing and the name "lunarNic_harshMistressNotes"
containing other descriptive text.
</t>
<figure anchor="json_example_with_extra_values">
<preamble>
Consider the following JSON response with JSON names, some of which should be ignored
by clients without knowledge of their meaning.
</preamble>
<artwork>
{
"handle" : "ABC123",
"lunarNic_beforeOneSmallStep" : "TRUE THAT!",
"remarks" : [
"she sells seas shells",
"down by the seashore"
],
"lunarNic_harshMistressNotes" : [
"In space,",
"nobody can hear you scream."
]
}
</artwork>
</figure>
<t>
Insertion of unrecognized names ignored by clients may also be used for
future revisions to specifications and specifications deriving extensions from
a base specification.
</t>
<t>
JSON names SHOULD only consist of the alphabetic ASCII characters A through Z in
both uppercase and lowercase, the numerical digits 0 through 9, underscore
characters, and SHOULD NOT begin with
an underscore character, numerical digit or the characters "xml". The following
describes the produciton of JSON names in <xref target="RFC5234">ABNF</xref>.</t>
<figure anchor="json_name_abnf">
<preamble>
ABNF for JSON names
</preamble>
<artwork>
name = ALPHA *( ALPHA / DIGIT / "_" )
</artwork>
</figure>
<t> This restriction
is a union
of the Ruby programming language identifier syntax and the XML element name
syntax and has two purposes. First, client implementers using modern programming
languages such as Ruby or Java may use libraries that automatically promote JSON
names to first order object attributes or members (e.g. using the example above,
the values may be referenced as network.handle or network.lunarNic_beforeOneSmallStep).
Second, a clean mapping between JSON and XML is easy to accomplish using the JSON
representation.
</t>
<t> Clients processing JSON responses MUST be prepared for values specified in the
registry response documents to be absent from a response as no JSON value
listed is required to appear in the response. In other words, servers MAY remove
values as is needed by the policies of the server operator.</t>
</section>
</section>
<section title="Use of XML">
<section title="Signaling">
<t>
Clients may signal their desire for XML using the "application/xml" media type
or a more application specific XML media type.
</t>
</section>
<section title="Naming and Structure">
<t>
Well-formed XML may be programmatically produced using the JSON encodings
due to the JSON naming rules outlined in <xref target="json_naming"/> and
the following simple rules:
<list style="numbers">
<t>Where a JSON name is given, the corresponding XML element has the
same name.</t>
<t>Where a JSON value is found, it is the content of the corresponding
XML element.</t>
<t>Where a JSON value is an array, the XML element is to be repeated
for each element of the array.</t>
<t>The root tag of the XML document is to be "response".</t>
</list>
</t>
<figure anchor="json_example_to_convert">
<preamble>
Consider the following JSON response.
</preamble>
<artwork>
{
"startAddress" : "10.0.0.0",
"endAddress" : "10.0.0.255",
"remarks" : [
"she sells seas shells",
"down by the seashore"
],
"uris" : [
{
"type" : "source",
"uri" : "http://whois-rws.net/network/xxxx"
},
{
"type" : "parent",
"uri" : "http://whois-rws.net/network/yyyy"
}
]
}
</artwork>
</figure>
<figure>
<preamble>
The corresponding XML would look like this:
</preamble>
<artwork>
<response>
<startAddress>10.0.0.0</startAddress>
<endAddress>10.0.0.255</endAddress>
<remarks>She sells sea shells</remarks>
<remarks>down by the seashore</remarks>
<uris>
<type>source</type>
<uri>http://whois-rws.net/network/xxxx</uri>
</uris>
<uris>
<type>parent</type>
<uri>http://whois-rws.net/network/yyyy</uri>
</uris>
</response>
</artwork>
</figure>
<t>
JSON values converted to XML element content MUST be properly
escaped. XML offers various means for escaping data, but such escaping
MUST account for the '<', '>', and '&' characters and
MUST redact all C0 control characters except tab, carriage return, and
new-line. (Redaction of disallowed control characters is a protocol
requirement, though in practice most Internet registries do not allow
this data in their data stores and therefore do not need to account
for this rule.)
</t>
<t>
The rules for clients processing XML responses are the same as those with
JSON: clients SHOULD ignore unrecognized XML elements, and servers MAY insert
XML elements with tag names according to the naming rules in
<xref target="json_naming"/>. And as with JSON, clients MUST be prepared for
XML elements specified in the
registry response documents to be absent from a response as no XML element
listed is required to appear in the response.
</t>
</section>
</section>
<section title="Common Error Response Body" anchor="common_error_body">
<t>
As specified in <xref target="http_responses"/>, some non-answer responses may
return entity bodies with information that could be more descriptive.
</t>
<t>
The basic structure of that response is a data class containing an error code
number (corresponding to the HTTP response code) followed by a string named
"title" followed by an array of strings named "description".
</t>
<figure anchor="json_common_error">
<preamble>This is an example of the JSON version of the common response body.</preamble>
<artwork>
{
"errorCode": 418
"title": "Your beverage choice is not available",
"description": [
"I know coffee has more ummppphhh.",
"But I cannot provide." ]
}
</artwork>
</figure>
<figure anchor="xml_common_error">
<preamble>This is an example of the XML version of the common response body.</preamble>
<artwork>
<response>
<errorCode>418</errorCode>
<title>Your beverage choice is not available</title>
<description>I know coffee has more ummppphhh.</description>
<description>But I cannot provide.</description>
</response>
</artwork>
</figure>
<t>
The media type for the JSON structure is "application/rdap_error+json" and
the media type for the XML document is "application/rdap_error+xml". Conformance
to this specification is considered to be level 0 for both media types.
</t>
<t>
A client MAY simply use the HTTP response code as the server is not required to
include error data in the response body. However, if a client wishes to parse the
error data, it SHOULD first check that the Content-Type header contains the appropriate
media type.
</t>
</section>
<section title="Common Data Structures">
<t>
This section defines two common data structures to be used by DNRD-AP, NRRD-AP, and
other RD-AP protocols. As such, the names identifying these data structures are not to be
redefined by any registry specific RD-AP specifications. Each of these datatypes MAY
appear within any other data object of a response, but the intended purpose is that they
will be mostly used in the top-most data object of a response.
</t>
<t>
The first data structure is named "rdapConformance" and is simply an array of
strings, each providing a hint as to the specifications used in the construction
of the response.
</t>
<figure anchor="rdapConformance">
<preamble>An example rdapConformance data structure.</preamble>
<artwork>
"rdapConformance" : [
"nrrdap_level_0"
]
</artwork>
</figure>
<t>
The second data structure is named "notices" and is an array of "notice"
objects. Each "notice" object contains a "title" string representing the
title of the notice object, an array of strings named "description" for the
purposes of conveying any descriptive text about the notice, and a "uri"
string holding a URI referencing a service that may provide additional
information about the notice.
</t>
<figure anchor="notices">
<preamble>An exmaple of the notices data structure.</preamble>
<artwork>
"notices" : [
"notice" : {
"title" : "Terms of Use",
"description" : [
"This service is subject to The Registry of the Moons",
"terms of service."
],
"uri" : "http://example.com/our-terms-of-use"
}
]
</artwork>
</figure>
<figure anchor="json_example_with_notices_and_rdapConformance">
<preamble>
This is an example response with both rdapConformance and notices embedded.
</preamble>
<artwork>
{
"rdapConformance" : [
"nrrdap_level_0"
]
"notices" : [
"notice" : {
"title" : "Content Redacted",
"description" : [
"Without full authorization, content has been redacted.",
"Sorry, dude!"
],
"uri" : "http://example.com/our-redaction-policies"
}
]
"startAddress" : "10.0.0.0",
"endAddress" : "10.0.0.255",
"remarks" : [
"she sells seas shells",
"down by the seashore"
],
"uris" : [
{
"type" : "source",
"uri" : "http://whois-rws.net/network/xxxx"
},
{
"type" : "parent",
"uri" : "http://whois-rws.net/network/yyyy"
}
]
}
</artwork>
</figure>
</section>
<section title="Common Datatypes">
<t>
This section describes common data types found in Internet registries, the
purpose being a common and normalized list of normative references to
other specifications to be used by multiple RD-AP applications. Unless otherwise
stated by the response specification of an Internet registry using this specification
as a basis, the data types can assume to be as follows:
<list style="numbers">
<t>IPv4 addresses - <xref target="RFC0791"></xref></t>
<t>IPv6 addresses - <xref target="RFC5952"></xref></t>
<t>country code - <xref target="ISO.3166.1988"></xref></t>
<t>domain name - <xref target="RFC4343"></xref></t>
<t>email address - <xref target="RFC5322"></xref></t>
<t>date and time strings - <xref target="RFC3339"/></t>
</list>
</t>
</section>
<section title="IANA Considerations">
<section title="IANA Registry for RDAP Extensions">
<t>
This specification proposes an IANA registry for RDAP extensions. The
purpose of this registry is to ensure uniqueness of extension identifier.
The extension identifier is used as prefix in JSON names and as a prefix
of path segments in RDAP URLs.
</t>
<t>
The production rule for JSON names in response is specified in <xref target="json_naming"/>.
</t>
<t>
In accordance with RFC5226, the IANA policy for assigning new values shall
be Specification Required: values and their meanings must be documented in
an RFC or in some other permanent and readily available reference, in
sufficient detail that interoperability between independent implementations
is possible.
</t>
<t>
The following is a preliminary template for an RDAP extension registration:
<list style="empty">
<t>Extension identifier: the identifier of the extension</t>
<t>Registry operator: the name of the registry operator</t>
<t>Published specification: RFC number, bibliographical reference or URL
to a permenant and readily available specification</t>
<t>Person & email address to contact for further information:
The names and email addresses of individuals for contact regarding this registry entry
</t>
<t>Intended usage: brief reasons for this registry entry</t>
</list>
</t>
<t>
The following is an example of a regstration in the RDAP extension registry:
<list style="empty">
<t>Extension identifier: lunarNic</t>
<t>Registry operator: The Registry of the Moon, LLC</t>
<t>Published specification: http://www.example/moon_apis/rdap</t>
<t>Person & email address to contact for further information:
Professor Bernardo de la Paz <berny&moon.example>
</t>
<t>Intended usage: COMMON</t>
</list>
</t>
</section>
<section title="Registration of RDAP Media Type for JSON">
<t>
This specification registers the "application/rdap+json" media type.
<list>
<t>Type name: application</t>
<t>Subtype name: rdap+json</t>
<t>Required parameters: n/a</t>
<t>Optional parameters: level</t>
<t>Encoding considerations: n/a</t>
<t>Security considerations: n/a</t>
<t>Interoperability considerations: n/a</t>
<t>Published specification: [[ this document ]]</t>
<t>Applications that use this media type: RDAP</t>
<t>Additional information: n/a</t>
<t>Person & email address to contact for further information: Andy Newton &andy@hxr.us&</t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: none</t>
<t>Author: Andy Newton</t>
<t>Change controller: IETF</t>
</list>
</t>
</section>
<section title="Registration of RDAP Media Type for XML">
<t>
This specification registers the "application/rdap+xml" media type.
<list>
<t>Type name: application</t>
<t>Subtype name: rdap+xml</t>
<t>Required parameters: n/a</t>
<t>Optional parameters: level</t>
<t>Encoding considerations: n/a</t>
<t>Security considerations: n/a</t>
<t>Interoperability considerations: n/a</t>
<t>Published specification: [[ this document ]]</t>
<t>Applications that use this media type: RDAP</t>
<t>Additional information: n/a</t>
<t>Person & email address to contact for further information: Andy Newton &andy@hxr.us&</t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: none</t>
<t>Author: Andy Newton</t>
<t>Change controller: IETF</t>
</list>
</t>
</section>
</section>
<section title="Internationalization Considerations">
<section title="URIs vs IRIs">
<t>
Clients MAY use IRIs as they see fit, but MUST transform them to
<xref target="RFC3986">URIs</xref> for interaction with RD-AP servers.
RD-AP servers MUST use URIs in all responses, and clients MAY transform
these URIs to IRIs.
</t>
</section>
<section title="Character Encoding">
<t>
The default text encoding for JSON and XML responses in RD-AP is UTF-8,
and all servers and clients MUST support UTF-8. Servers and clients MAY
optionally support other character encodings.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="draft-kucherawy-weirds-requirements">
<front>
<title>Requirements For Internet Registry Services</title>
<author initials="M." surname="Kucherawy" fullname="M. Kucherawy">
<organization>Cloudmark</organization>
</author>
<date day="2" month="April" year="2011"/>
</front>
<seriesInfo name="Work in progress: Internet Drafts"
value="draft-kucherawy-weirds-requirements-04.txt"/>
</reference>
<reference anchor="SAC-051">
<front>
<title>SSAC Report on Domain Name WHOIS Terminology and Structure</title>
<author initials="D." surname="Piscitello" role="editor" />
<date day="19" month="September" year="2011"/>
</front>
</reference>
<reference anchor="RFC4627">
<front>
<title>The application/json Media Type for JavaScript Object Notation
(JSON)</title>
<author initials="D." surname="Crockford" fullname="D. Crockford">
<organization/>
</author>
<date year="2006" month="July"/>
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from the
ECMAScript Programming Language Standard. JSON defines a small set of
formatting rules for the portable representation of structured data.
This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4627"/>
<format type="TXT" octets="16319" target="http://www.rfc-editor.org/rfc/rfc4627.txt"
/>
</reference>
<reference anchor="RFC3339">
<front>
<title>Date and Time on the Internet: Timestamps</title>
<author initials="G." surname="Klyne" fullname="Graham Klyne" role="editor">
<organization>Clearswift Corporation</organization>
<address><postal><street>1310 Waterside</street><street>Arlington Business Park</street><city>Theale</city><region>Reading</region><code>RG7 4SA</code><country>UK</country></postal><phone>+44 11 8903 8903</phone><facsimile>+44 11 8903 9000</facsimile><email>GK@ACM.ORG</email></address>
</author>
<author initials="C." surname="Newman" fullname="Chris Newman">
<organization>Sun Microsystems</organization>
<address><postal><street>1050 Lakes Drive, Suite 250</street><city>West Covina</city><region>CA</region><code>91790</code><country>USA</country></postal><email>chris.newman@sun.com</email></address>
</author>
<date year="2002" month="July"/>
<abstract>
<t> This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 standard for representation
of dates and times using the Gregorian calendar. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="3339"/>
<format type="TXT" octets="35064" target="http://www.rfc-editor.org/rfc/rfc3339.txt"/>
<format type="HTML" octets="61277"
target="http://xml.resource.org/public/rfc/html/rfc3339.html"/>
<format type="XML" octets="37259"
target="http://xml.resource.org/public/rfc/xml/rfc3339.xml"/>
</reference>
<reference anchor="RFC4034">
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author initials="R." surname="Arends" fullname="R. Arends">
<organization/>
</author>
<author initials="R." surname="Austein" fullname="R. Austein">
<organization/>
</author>
<author initials="M." surname="Larson" fullname="M. Larson">
<organization/>
</author>
<author initials="D." surname="Massey" fullname="D. Massey">
<organization/>
</author>
<author initials="S." surname="Rose" fullname="S. Rose">
<organization/>
</author>
<date year="2005" month="March"/>
<abstract>
<t>This document is part of a family of documents that describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of resource records and protocol modifications that provide
source authentication for the DNS. This document defines the public key
(DNSKEY), delegation signer (DS), resource record digital signature
(RRSIG), and authenticated denial of existence (NSEC) resource records.
The purpose and format of each resource record is described in detail,
and an example of each resource record is given.</t>
<t> This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4034"/>
<format type="TXT" octets="63879" target="http://www.rfc-editor.org/rfc/rfc4034.txt"
/>
</reference>
<reference anchor="RFC0791">
<front>
<title abbrev="Internet Protocol">Internet Protocol</title>
<author initials="J." surname="Postel" fullname="Jon Postel">
<organization>University of Southern California (USC)/Information Sciences
Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal></address>
</author>
<date year="1981" day="1" month="September"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<format type="TXT" octets="97779" target="http://www.rfc-editor.org/rfc/rfc791.txt"
/>
</reference>
<reference anchor='RFC5952'>
<front>
<title>A Recommendation for IPv6 Address Text Representation</title>
<author initials='S.' surname='Kawamura' fullname='S. Kawamura'>
<organization /></author>
<author initials='M.' surname='Kawashima' fullname='M. Kawashima'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5952' />
<format type='TXT' octets='26570' target='http://www.rfc-editor.org/rfc/rfc5952.txt' />
</reference>
<reference anchor="ISO.3166.1988">
<front>
<title>Codes for the representation of names of countries, 3rd
edition</title>
<author>
<organization>International Organization for
Standardization</organization>
</author>
<date day="15" month="August" year="1988"/>
</front>
<seriesInfo name="ISO" value="Standard 3166"/>
</reference>
<reference anchor='RFC5396'>
<front>
<title>Textual Representation of Autonomous System (AS) Numbers</title>
<author initials='G.' surname='Huston' fullname='G. Huston'>
<organization /></author>
<author initials='G.' surname='Michaelson' fullname='G. Michaelson'>
<organization /></author>
<date year='2008' month='December' />
<abstract>
<t>A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number. This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5396' />
<format type='TXT' octets='5373' target='http://www.rfc-editor.org/rfc/rfc5396.txt' />
</reference>
<reference anchor='RFC4343'>
<front>
<title>Domain Name System (DNS) Case Insensitivity Clarification</title>
<author initials='D.' surname='Eastlake' fullname='D. Eastlake'>
<organization /></author>
<date year='2006' month='January' />
<abstract>
<t>Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4343' />
<format type='TXT' octets='22899' target='http://www.rfc-editor.org/rfc/rfc4343.txt' />
</reference>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='213584' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='RFC5322'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='Peter W.
Resnick' role='editor'>
<organization>Qualcomm Incorporated</organization>
<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-1714</code>
<country>US</country></postal>
<phone>+1 858 651 4478</phone>
<email>presnick@qualcomm.com</email>
<uri>http://www.qualcomm.com/~presnick/</uri></address></author>
<date year='2008' month='October' />
<abstract>
<t>This document specifies the Internet
Message Format (IMF), a syntax for text messages
that are sent between computer users, within
the framework of "electronic mail"
messages. This specification is a revision of
Request For Comments (RFC) 2822, which
itself superseded Request For Comments (RFC)
822, "Standard for the Format of ARPA
Internet Text Messages", updating it to
reflect current practice and incorporating
incremental changes that were specified in
other RFCs.</t></abstract></front>
<seriesInfo name='RFC' value='5322' />
<format type='TXT' octets='122322' target='http://www.rfc-editor.org/rfc/rfc5322.txt' />
<format type='HTML' octets='213342' target='http://xml.resource.org/public/rfc/html/rfc5322.html' />
<format type='XML' octets='174183' target='http://xml.resource.org/public/rfc/xml/rfc5322.xml' />
</reference>
<reference anchor="RFC2616">
<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer
Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address>
</author>
<author initials="J." surname="Gettys" fullname="James Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address>
</author>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address>
</author>
<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address>
</author>
<author initials="P." surname="Leach" fullname="Paul J. Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address>
</author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address>
</author>
<date year="1999" month="June"/>
<abstract>
<t> The Hypertext Transfer Protocol (HTTP) is an application-level protocol
for distributed, collaborative, hypermedia information systems. It is a
generic, stateless, protocol which can be used for many tasks beyond its
use for hypertext, such as name servers and distributed object
management systems, through extension of its request methods, error
codes and headers . A feature of HTTP is the typing and negotiation of
data representation, allowing systems to be built independently of the
data being transferred. </t>
<t> HTTP has been in use by the World-Wide Web global information initiative
since 1990. This specification defines the protocol referred to as
"HTTP/1.1", and is an update to RFC 2068 . </t>
</abstract>
</front>
<seriesInfo name="RFC" value="2616"/>
<format type="TXT" octets="422317"
target="http://www.rfc-editor.org/rfc/rfc2616.txt"/>
<format type="PS" octets="5529857" target="http://www.rfc-editor.org/rfc/rfc2616.ps"/>
<format type="PDF" octets="550558"
target="http://www.rfc-editor.org/rfc/rfc2616.pdf"/>
<format type="HTML" octets="636125"
target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="493420"
target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>
</references>
<section title="Cache Busting" anchor="cache-busting">
<t>
To overcome issues with misbehaving <xref target="RFC2616">HTTP</xref> cache infrastructure, clients may use the
adhoc and improbably used query parameter with a random value of their choosing. As <xref target="parameters"></xref>
instructs servers to ignore unknown parameters, this is unlikely to have any known side effects.
</t>
<figure>
<preamble>
An example of using an unknown query parameter to bust caches:
</preamble>
<artwork>
http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123
</artwork>
</figure>
<t>
Use of an unknown parameter to overcome misbehaving caches is not part of any specification
and is offered here for informational purposes.
</t>
</section>
<section title="Changelog">
<t>
<list style="hanging">
<t hangText="Initial WG -00:">Updated to working group document 2012-September-20</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:50:12 |