<?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-02" 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>
        <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>
        <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 <xref target="RFC3986">URL</xref> patterns
                presented here are only applicable to the <xref target="RFC2616">HTTP</xref> 
                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 bodies.
            </t>
        </section>
        <section title="Congruence With Other Registry Data Access Protocols">
            <t>
                This document describes the URL patterns for a Number Resource Registry Data
                Access Protocol (NRRD-AP) and describes a Registry Data Access Protocol (RD-AP)
                adhering to <xref target="I-D.designteam-weirds-using-http"></xref>, the intent
                being a specification for number resource registries useful and in the style
                similar to other registry access protocols, such as Domain Name Registry Access
                Protocols (DNRP-AP).
            </t>
        </section>
        <section title="Path Specification">
            <t>
                The uniform patterns start with a base <xref target="RFC3986">URL</xref> 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="symbols">
                    <t>'ip' : IP networks and associated data referenced using either an 
                    IPv4 or IPv6 address.</t>
                    <t>'autnum' : Autonomous system registrations and associated data referenced
                    using an AS Plain autonomous system number.</t>
                    <t>'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/... or /ip/XXX/YY/...
                    where the path segment following 'ip' is either an <xref target="RFC0791">IPv4</xref> or 
                    <xref target="RFC5952">IPv6</xref> address (i.e. XXX) or
                    an IPv4 or IPv6 <xref target="RFC4632">CIDR</xref> notation address block (i.e. XXX/YY). 
                    Semantically, the simpler
                    form using the address can be thought of as a CIDR block with a length of 32 for IPv4
                    and a length of 128 for IPv6. A given specific address or CIDR may fall within multiple
                    IP networks in a hierarchy of networks, therefore this query targets the "most-specific"
                    or lowest IP network which completely encompasses it in a hierarchy of IP networks.
                </t>
                <t>
                    Path segments following the IP address or CIDR notation target specific information associated with the
                    targetted IP network in the following way:
                    <list style="symbols">
                        <t>'registration' : The query is for the network registration data.</t>
                        <t>'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 <xref target="RFC3986">URL</xref> 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 IP network registration information
                    for the most specific IP network starting with 192.0.2.0 and ending with 192.0.2.255.</preamble>
                    <artwork>
                        
  http://example.com/somepath/ip/192.0.2.0/24/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>
                <figure>
                    <preamble>This is an example of a URL for both the registration and operator information of
                    the most specific network containing 192.0.2.0/24.</preamble>
                    <artwork>
                        
  http://example.com/somepath/ip/192.0.2.0/24                      
                        
                    </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>
                    </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 <xref target="RFC5396">autonomous system number</xref>. 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 <xref target="RFC4343">fully-qualified domain name</xref> 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>
    </middle>
    <back>
        <references title="Normative References">
            <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="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='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='RFC4632'>
                
                <front>
                    <title>Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan</title>
                    <author initials='V.' surname='Fuller' fullname='V. Fuller'>
                        <organization /></author>
                    <author initials='T.' surname='Li' fullname='T. Li'>
                        <organization /></author>
                    <date year='2006' month='August' />
                    <abstract>
                        <t>This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state.  This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
                
                <seriesInfo name='BCP' value='122' />
                <seriesInfo name='RFC' value='4632' />
                <format type='TXT' octets='66944' target='http://www.rfc-editor.org/rfc/rfc4632.txt' />
            </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='I-D.designteam-weirds-using-http'>
                <front>
                    <title>Using HTTP for RESTful Whois Services by Internet Registries</title>
                    
                    <author initials='A' surname='Newton' fullname='Andrew Newton'>
                        <organization />
                    </author>
                    
                    <author initials='K' surname='Ranjbar' fullname='Kaveh Ranjbar'>
                        <organization />
                    </author>
                    
                    <author initials='A' surname='Servin' fullname='Arturo Servin'>
                        <organization />
                    </author>
                    
                    <author initials='B' surname='Ellacott' fullname='Byron Ellacott'>
                        <organization />
                    </author>
                    
                    <author initials='S' surname='Hollenbeck' fullname='Scott Hollenbeck'>
                        <organization />
                    </author>
                    
                    <author initials='S' surname='Sheng' fullname='Steve Sheng'>
                        <organization />
                    </author>
                    
                    <author initials='F' surname='Arias' fullname='Francisco Arias'>
                        <organization />
                    </author>
                    
                    <author initials='N' surname='Kong' fullname='Ning Kong'>
                        <organization />
                    </author>
                    
                    <author initials='F' surname='Obispo' fullname='Francisco Obispo'>
                        <organization />
                    </author>
                    
                    <date month='May' day='10' year='2012' />
                    
                    <abstract><t>This document describes the use of HTTP in Whois services using RESTful web methodologies.</t></abstract>
                    
                </front>
                
                <seriesInfo name='Internet-Draft' value='draft-designteam-weirds-using-http-01' />
                <format type='TXT'
                    target='http://www.ietf.org/internet-drafts/draft-designteam-weirds-using-http-01.txt' />
            </reference>
        </references>
    </back>
</rfc>