One document matched: draft-faltstrom-uri-07.xml
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3761 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3958 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml">
<!ENTITY rfc3401 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3401.xml">
<!ENTITY rfc3403 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3403.xml">
<!ENTITY rfc3404 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3404.xml">
<!ENTITY rfc1035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc4592 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4592.xml">
<!ENTITY rfc4848 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4848.xml">
<!ENTITY rfc2929 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2929.xml">
<!ENTITY rfc3986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc2782 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY rfc5507 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5507.xml">
<!ENTITY rfc3629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY rfc3987 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
<!ENTITY rfc5890 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY rfc6195 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6195.xml">
<!ENTITY rfc3597 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<rfc docName="draft-faltstrom-uri-07" ipr="trust200902" category="std" updates="3404, 3959" obsoletes="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="URI Resource Record">The Uniform Resource Identifier (URI) DNS Resource Record </title>
<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization abbrev="Netnod">Netnod</organization>
<address>
<email>paf@netnod.se</email>
</address>
</author>
<author fullname="Olaf Kolkman" initials="O." surname="Kolkman">
<organization abbrev="NLnet Labs">NLnet Labs</organization>
<address>
<email>olaf@NLnetLabs.nl</email>
</address>
</author>
<date month="January" year="2013" day="22"/>
<area>Operations</area>
<keyword>DNS</keyword>
<keyword>Applications</keyword>
<keyword>RFC</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. </t>
<t>This document updates RFC 3958 and RFC 3404. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction" toc="default">
<t>This document explains the use of the Domain Name System
(DNS) for the storage of URIs, and how to resolve hostnames to
such URIs that can be used by various applications. For
resolution the application need to know both the hostname and
the protocol that the URI is to be used for. The protocol is
registered by IANA. </t>
<t>Currently, looking up URIs given a hostname uses
the <xref target="RFC3401" pageno="false"
format="default">DDDS</xref> application framework with the DNS
as a database as specified in <xref target="RFC3404"
pageno="false" format="default">RFC 3404</xref>. This has a
number of implications such as the inability to select what
NAPTR records that match the query are interesting. The RRSet
returned will always consist of all URIs "connected" with the
domain in question. </t>
<t>The URI resource record specified in this document enables
the querying party to select which ones of the NAPTR records one
is interested in. This because data in the service field of the
NAPTR record is included in the owner part of the URI resource
record type. </t>
<t>Querying for URI resource records is not replacing querying
for NAPTR resource records (or use of <xref target="RFC3958"
pageno="false" format="default">S-NAPTR</xref>). Instead, the
URI resource record type provides a complementary mechanism to
use when one already knows what service field is
interesting. With it, one can directly query for the specific
subset of the otherwise possibly large RRSet given back when
querying for NAPTR resource records. </t>
<t>This document updates RFC 3958 and RFC 3404 by adding the flag "D" to the list of defined terminal flags in section 2.2.3 of RFC 3958 and 4.3 of RFC 3404. </t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, <xref target="RFC2119" pageno="false" format="default">RFC 2119</xref>. </t>
</section>
<section title="Applicability Statement" toc="default">
<t>In general, it is expected that URI records will be used by
clients for applications where the relevant protocol to be used
is known, but, for example, an extra abstraction is needed in
order to separate a domain name from a point of service (as
addressed by the URI). One example of such a situation is when
an organisation has many domain names, but only one official web
page. </t>
<t>Applications MUST know the specific service fields to prepend
the hostname with. Using repetitive queries for URI records
MUST NOT be a replacement for querying for NAPTR records
according to the NAPTR (DDDS) or S-NAPTR algorithms. NAPTR
records serve the purpose to discover the various services and
URIs for looking up access points for a given service. Those
are two very different kinds of needs. </t>
</section>
<section title="DNS considerations" toc="default">
<t>Using prefix labels, such as underscored service tags,
prevents the use of wildcards, as constructs as
_s2._s1.*.example.net. are not possible in the DNS,
see <xref target="RFC4592" pageno="false" format="default">RFC
4592</xref>. Besides, underscored service tags used for the URI
RR (based on the NAPTR service descriptions) may have slightly
different semantics than service tags used for underscored
prefix labels that are used in combination with other (yet
unspecified) RR types. This may cause subtle management problems
when delegation structure that has developed within the context
of URI RRs is also to be used for other RR types. Since the
service labels might be overloaded, applications should
carefully check that the application level protocol is indeed
the protocol they expect. </t>
<t>Subtle management issues may also arise when the delegations from service to sub service label involves several parties and different stake holders. </t>
</section>
<section anchor="format" title="The format of the URI RR" toc="default">
<t>This is the presentation format of the URI RR: </t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
Ownername TTL Class URI Priority Weight Target
</artwork>
</figure>
<t>The URI RR does not cause any kind of Additional Section processing. </t>
<section title="Ownername, class and type" toc="default">
<t>The URI ownername is subject to special conventions. </t>
<t>Just like the <xref target="RFC2782" pageno="false"
format="default">SRV RR</xref> the URI RR has service
information encoded in its ownername. In order to encode the
service for a specific owner name one uses service
parameters. Valid service parameters used are those used for
SRV resource records, or registered by IANA for Enumservice
Registrations. The Enumservice Registration parameters are
reversed (subtype(s) before type), prepended with an
underscore (_) and prepended to the owner name in separate
labels. The underscore is prepended to the service parameters
to avoid collisions with DNS labels that occur in nature, and
the order is reversed to make it possible to do delegations,
if needed, to different zones (and therefore providers of
DNS). </t>
<t>It should be noted that the usage of a prefix must be described in detail in for example the Enumservice Registration documentation, or in a specific document that clarifies potential overload of parameters in the same URI. Specifically, registered URI schemes are not automatically acceptable as a service. With the HTTP scheme, one can for example have multiple methods (GET, PUT, etc), and this with the same URI. </t>
<t>For example, suppose we are looking for the URI for a service with Service Parameter "A:B:C" for host example.com.. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI") </t>
<t>The type number for the URI record is 256. </t>
<t>The URI resource record is class independent. </t>
<t>The URI RR has no special TTL requirements. </t>
</section>
<section title="Priority" toc="default">
<t>The priority of the target URI in this RR. Its range is 0-65535. A client MUST attempt to contact the URI with the lowest-numbered priority it can reach; URIs with the same priority SHOULD be tried in the order defined by the weight field. </t>
</section>
<section title="Weight" toc="default">
<t>A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. </t>
</section>
<section title="Target" toc="default">
<t>The URI of the target, enclosed in double-quote characters ('"'). Resolution of the URI is according to the definitions for the Scheme of the URI. </t>
<t>The URI is encoded as one or more <character-string> <xref target="RFC1035" pageno="false" format="default">RFC1035 section 3.3</xref>. </t>
</section>
<section anchor="wireformat" title="URI RDATA Wire Format" toc="default">
<t>The RDATA for a URI RR consists of a 2 octet Priority field, a two octet Weight field, and a variable length target field. </t>
<t>Priority and Weight are unsigned integers in network byte order. </t>
<t>The Target field contains the URI (without the enclosing double- quote characters used in the presentation format), encoded as a sequence of one or more <character-string> (as specified in section 3.3 of <xref target="RFC1035" pageno="false" format="default">RFC 1035</xref>), where all but the last <character-string> are filled up to the maximum length of 255 octets. </t>
<t>The Target field can also contain an IRI, but with the additional requirements that it is in <xref target="RFC3629" pageno="false" format="default">UTF-8</xref> and possible to convert to a URI according to section 3.1 of <xref target="RFC3987" pageno="false" format="default">RFC 3987</xref> and back again to an IRI according to section 3.2. Other character sets than UTF-8 are not allowed. The domain name part of the IRI can be either an U-LABEL or A-LABEL as defined in <xref target="RFC5890" pageno="false" format="default">RFC 5890</xref>. </t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Target /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
</section>
<section title="Definition of the flag 'D' for NAPTR records" toc="default">
<t>This document specifies the flag "D" for use as a flag in NAPTR records. The flag indicate a terminal NAPTR record because it denotes the end of the DDDS/NAPTR processing rules. In the case of a "D" flag, the Replacement field in the NAPTR record, prepended with the service flags, is used as the Owner of a DNS query for URI records, and normal URI processing as defined in this document is applied. </t>
<t>The replacement field MUST NOT include any of the service parameters. Those are to be prepended (together with underscore) as described in other places in this document. </t>
<t>The Regexp field in the NAPTR record MUST be empty when the 'D' flag is in use. </t>
</section>
<section title="Examples" toc="default">
<section title="Homepage at one domain, but two domains in use" toc="default">
<t>An organisation has the domain names example.com and example.net, but the official URI http://www.example.com/. Given the service type "web" and subtype "http" (from the IANA registry), the following URI Resource Records could be made available in the respective zones (example.com and example.net): </t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
$ORIGIN example.com.
_http._web IN URI 10 1 "http://www.example.com/"
$ORIGIN example.net.
_http._web IN URI 10 1 "http://www.example.com/"
</artwork>
</figure>
</section>
</section>
<section title="Relation to S-NAPTR" toc="default">
<t>The URI resource record type is not a replacement for the S-NAPTR. It is instead an extension and the seond step of the S-NAPTR resolution can resolve a URI resource record instead of using SRV records and yet another algorithm for how to use SRV records for the specific protocol. </t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
$ORIGIN example.com.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.example.com. ; replacement
_ProtA._tcp IN URI "schemeA:service.example.com/example"
</artwork>
</figure>
</section>
<section title="Relation to U-NAPTR" toc="default">
<t>The URI Resource Record Type, together with S-NAPTR, can be viewed as a replacement for <xref target="RFC4848" pageno="false" format="default">U-NAPTR</xref>. The URI Resource Record Type is though only interesting when one know a base domain name, a protocol and service so that one can compose the record to look up. NAPTR records of any kind are used to look up what services exists for a certain domain, which is one step before the URI resource record is used. </t>
</section>
<section title="Relation to SRV" toc="default">
<t>The URI Resource Record Type can be viewed as a replacement for the SRV record. This because it like the SRV record can only be looked up if one know the base domain, the protocol and the service. It has a similar functionality, but instead of returning a hostname and port number, the URI record return a full URI. As such, it can be viewed as a more powerful resource record than SRV. </t>
</section>
<section title="IANA Considerations" toc="default">
<section title="Registration of the URI Resource Record Type" toc="default">
<t>After an expert review in February 2011 (see <xref target="alloc-request" pageno="false" format="default"/>) IANA has allocated RRTYPE 256 for the URI Resource Record Type in the registry named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 <xref target="RFC6195" pageno="false" format="default">RFC 6195</xref>, located at http://www.iana.org/assignments/dns-parameters. </t>
<t>IANA is requested to update the reference with that registration to this RFC. </t>
</section>
<section title="Registration of services" toc="default">
<t>No new registry is needed for the registration of services as the Enumservice Registrations registry is used also for the URI resource record type. </t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>The authors do not believe this resource record cause any new security problems. Deployment must though be done in a proper way as misconfiguration of this resource record might make it impossible to reach the service that was originally intended to be accessed. </t>
<t>Using the URI resource record together with security mechanisms that relies on verification of authentication of hostnames, like TLS, makes it important to choose the correct domain name when doing the comparison. </t>
<t>The basic mechanism works as follows: </t>
<t><list style="hanging" hangIndent="5"><t hangText="1.">Announce the fact example.com is hosted at example.org (with some URL) in DNS </t><t hangText="2.">Secure the URI resource record with DNSSEC. </t><t hangText="3.">Verify the TLS (for example) certificate for the connection to example.org matches, i.e. use the hostname in the URI and not the hostname used originally when looking up the URI resource record. </t><t hangText="4.">If needed, do application layer authentication etc over the then encrypted connection. </t></list> </t>
<t>What also can happen is that the URI in the resource record type has errors in it. Applications using the URI resource record type for resolution should behave similarly as if the user typed (or copy and pasted) the URI. At least it must be clear to the user that the error is not due to any error from his side. </t>
<t>One SHOULD NOT include userinfo (see User Information, Section 3.2.1, in <xref target="RFC3986" pageno="false" format="default">RFC 3986</xref>) in a URI that is used in a URI resource record as DNS data must be viewed as publicly available information. </t>
</section>
<section title="Acknowledgements" toc="default">
<t>Ideas on how to split the two different kind of queries "What services exists for this domain name" and "What is the URI for this service" came from Scott Bradner and Lawrence Conroy. Other people that have contributed to this document include Richard Barnes, Leslie Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz. </t>
</section>
</middle>
<back>
<section anchor="alloc-request" title="The original RRTYPE Allocation Request" toc="default">
<t>On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource record based on a request that followed the procedure documented in <xref target="RFC6195" pageno="false" format="default">RFC 6195</xref>. The DNS RRTYPE PARAMETER ALLOCATION form as submitted to IANA at thet time is replicated below for reference. </t>
<t><list style="hanging" hangIndent="5"><t hangText="A.">Submission Date: <vspace blankLines="1"/> May 23, 2009 <vspace blankLines="1"/> </t><t hangText="B.">Submission Type: <vspace blankLines="1"/> [X] New RRTYPE <vspace blankLines="0"/> [ ] Modification to existing RRTYPE <vspace blankLines="1"/> </t><t hangText="C.">Contact Information for submitter: <vspace blankLines="1"/> Name: Patrik Faltstrom <vspace blankLines="0"/> Email Address: paf@cisco.com <vspace blankLines="0"/> International telephone number: +46-8-6859131 <vspace blankLines="0"/> Other contact handles: <vspace blankLines="0"/> (Note: This information will be publicly posted.) <vspace blankLines="1"/> </t><t hangText="D.">Motivation for the new RRTYPE application? <vspace blankLines="1"/> There is no easy way to get from a domain name to a URI (or IRI). Some mechanisms exists via use of the <xref target="RFC3403" pageno="false" format="default">NAPTR</xref> resource record. That implies quite complicated rules that are simplified via the <xref target="RFC3958" pageno="false" format="default">S-NAPTR</xref> specification. But, the ability to directly look up a URI still exists. This specification uses a prefix based naming mechanism originated in the definition of the <xref target="RFC2782" pageno="false" format="default">SRV</xref> resource record, and the RDATA is a URI, encoded as one text field. <vspace blankLines="1"/> See also <xref target="intro" pageno="false" format="default">above</xref>. <vspace blankLines="1"/> </t><t hangText="E.">Description of the proposed RR type. <vspace blankLines="1"/> The format of the URI resource record is as follows: <figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
Ownername TTL Class URI Priority Weight Target
</artwork></figure> The URI RR has service information encoded in its ownername. In order to encode the service for a specific owner name one uses service parameters. Valid service parameters used are either Enumservice Registrations registered by IANA, or prefixes used for the SRV resource record. <vspace blankLines="1"/> The wire format of the RDATA is as follows: <figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Target /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure> <vspace blankLines="1"/> </t><t hangText="F.">What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? <vspace blankLines="1"/> The RRTYPE that come closest is the NAPTR resource record. It is for example used in the DDDS and S-NAPTR algorithms. The main problem with the NAPTR is that selection of what record (or records) one is interested in is based on data stored in the RDATA portion of the NAPTR resource record. This, as explained in <xref target="RFC5507" pageno="false" format="default">RFC 5507</xref>, is not optimal for DNS lookups. Further, most applications using NAPTR resource records uses regular expression based rewrite rules for creation of the URI, and that has shown be complicated to implement. <vspace blankLines="1"/> The second closest RRTYPE is the SRV record that given a prefixed based naming just like is suggested for the URI resource record, one get back a port number and domain name. This can also be used for creation of a URI, but, only URIs without path components. <vspace blankLines="1"/> </t><t hangText="G.">What mnemonic is requested for the new RRTYPE (optional)? <vspace blankLines="1"/> URI <vspace blankLines="1"/> </t><t hangText="H.">Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters? <vspace blankLines="1"/> Yes, partially. <vspace blankLines="1"/> One of the mechanisms to select a service is to use the Enumservice Registry managed by IANA. Another is to use services and protocols used for SRV records. <vspace blankLines="1"/> </t><t hangText="I.">Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? <vspace blankLines="1"/> No <vspace blankLines="1"/> </t><t hangText="J.">Comments: <vspace blankLines="1"/> None <vspace blankLines="1"/> </t></list> </t>
</section>
<references title="Normative References"><reference anchor="RFC2119"><front><title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner" fullname="Scott Bradner"><organization>Harvard University</organization><address><postal><street>1350 Mass. Ave.</street><street>Cambridge</street><street>MA 02138</street></postal><phone>- +1 617 495 3864</phone><email>sob@harvard.edu</email></address></author><date year="1997" month="March"/><area>General</area><keyword>keyword</keyword><abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: <list><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. </t></list></t><t>Note that the force of these words is modified by the requirement level of the document in which they are used. </t></abstract></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/><format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/><format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/><format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/></reference> <reference anchor="RFC3958"><front><title>Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)</title><author initials="L." surname="Daigle" fullname="L. Daigle"><organization/></author><author initials="A." surname="Newton" fullname="A. Newton"><organization/></author><date year="2005" month="January"/><abstract><t>This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3958"/><format type="TXT" octets="54568" target="http://www.rfc-editor.org/rfc/rfc3958.txt"/></reference> <reference anchor="RFC1035"><front><title abbrev="Domain Implementation and Specification">Domain names - implementation and specification</title><author initials="P." surname="Mockapetris" fullname="P. Mockapetris"><organization>USC/ISI</organization><address><postal><street>4676 Admiralty Way</street><city>Marina del Rey</city><region>CA</region><code>90291</code><country>US</country></postal><phone>+1 213 822 1511</phone></address></author><date year="1987" day="1" month="November"/></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1035"/><format type="TXT" octets="125626" target="http://www.rfc-editor.org/rfc/rfc1035.txt"/></reference> <reference anchor="RFC3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><format type="TXT" octets="33856" target="http://www.rfc-editor.org/rfc/rfc3629.txt"/></reference> <reference anchor="RFC3987"><front><title>Internationalized Resource Identifiers (IRIs)</title><author initials="M." surname="Duerst" fullname="M. Duerst"><organization/></author><author initials="M." surname="Suignard" fullname="M. Suignard"><organization/></author><date year="2005" month="January"/><abstract><t>This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.</t><t> The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.</t></abstract></front><seriesInfo name="RFC" value="3987"/><format type="TXT" octets="111190" target="http://www.rfc-editor.org/rfc/rfc3987.txt"/></reference> <reference anchor="RFC5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><format type="TXT" octets="54245" target="http://www.rfc-editor.org/rfc/rfc5890.txt"/></reference> <reference anchor="RFC6195"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake" fullname="D. Eastlake"><organization/></author><date year="2011" month="March"/><abstract><t>This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6195"/><format type="TXT" octets="33790" target="http://www.rfc-editor.org/rfc/rfc6195.txt"/></reference> <!--<reference anchor="E164"> - <front> - <title>The International Public Telecommunication Number Plan</title> - <author> - <organization>ITU-T</organization> - </author> - <date month="May" year="1997"/> - </front> - <seriesInfo name="Recommendation" value="E.164"/> - </reference> --></references>
<references title="Non-normative references"><reference anchor="RFC3401"><front><title>Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS</title><author initials="M." surname="Mealling" fullname="M. Mealling"><organization/></author><date year="2002" month="October"/><abstract><t>This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.</t></abstract></front><seriesInfo name="RFC" value="3401"/><format type="TXT" octets="10172" target="http://www.rfc-editor.org/rfc/rfc3401.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="RFC3404"><front><title>Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)</title><author initials="M." surname="Mealling" fullname="M. Mealling"><organization/></author><date year="2002" month="October"/><abstract><t>This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3404"/><format type="TXT" octets="40124" target="http://www.rfc-editor.org/rfc/rfc3404.txt"/></reference> <reference anchor="RFC3403"><front><title>Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database</title><author initials="M." surname="Mealling" fullname="M. Mealling"><organization/></author><date year="2002" month="October"/><abstract><t>This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3403"/><format type="TXT" octets="31058" target="http://www.rfc-editor.org/rfc/rfc3403.txt"/></reference> <reference anchor="RFC3597"><front><title>Handling of Unknown DNS Resource Record (RR) Types</title><author initials="A." surname="Gustafsson" fullname="A. Gustafsson"><organization/></author><date year="2003" month="September"/><abstract><t>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3597"/><format type="TXT" octets="17559" target="http://www.rfc-editor.org/rfc/rfc3597.txt"/></reference> <reference anchor="RFC4592"><front><title>The Role of Wildcards in the Domain Name System</title><author initials="E." surname="Lewis" fullname="E. Lewis"><organization/></author><date year="2006" month="July"/><abstract><t>This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="4592"/><format type="TXT" octets="43991" target="http://www.rfc-editor.org/rfc/rfc4592.txt"/></reference> <reference anchor="RFC4848"><front><title>Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)</title><author initials="L." surname="Daigle" fullname="L. Daigle"><organization/></author><date year="2007" month="April"/><abstract><t>The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="4848"/><format type="TXT" octets="19341" target="http://www.rfc-editor.org/rfc/rfc4848.txt"/></reference> <reference anchor="RFC2782"><front><title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS SRV)</title><author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen"><organization>Troll Tech</organization><address><postal><street>Waldemar Thranes gate 98B</street><city>Oslo</city><region/><code>N-0175</code><country>NO</country></postal><phone>+47 22 806390</phone><facsimile>+47 22 806380</facsimile><email>arnt@troll.no</email></address></author><author initials="P." surname="Vixie" fullname="Paul Vixie"><organization>Internet Software Consortium</organization><address><postal><street>950 Charter Street</street><city>Redwood City</city><region>CA</region><code>94063</code><country>US</country></postal><phone>+1 650 779 7001</phone></address></author><author initials="L." surname="Esibov" fullname="Levon Esibov"><organization>Microsoft Corporation</organization><address><postal><street>One Microsoft Way</street><city>Redmond</city><region>WA</region><code>98052</code><country>US</country></postal><email>levone@microsoft.com</email></address></author><date year="2000" month="February"/><abstract><t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.</t></abstract></front><seriesInfo name="RFC" value="2782"/><format type="TXT" octets="24013" target="http://www.rfc-editor.org/rfc/rfc2782.txt"/></reference> <reference anchor="RFC5507"><front><title>Design Choices When Expanding the DNS</title><author><organization>IAB</organization></author><author initials="P." surname="Faltstrom" fullname="P. Faltstrom"><organization/></author><author initials="R." surname="Austein" fullname="R. Austein"><organization/></author><author initials="P." surname="Koch" fullname="P. Koch"><organization/></author><date year="2009" month="April"/><abstract><t>This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community.</t></abstract></front><seriesInfo name="RFC" value="5507"/><format type="TXT" octets="44045" target="http://www.rfc-editor.org/rfc/rfc5507.txt"/></reference> </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:14:04 |