One document matched: draft-crocker-dns-attrleaf-05.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:/var/tmp/CGItemp59640.xml"?>
<!-- automatically generated by xml2rfc v1.36 on 2011-03-30T07:45:31Z -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ ]>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc
category="bcp"
docName="draft-crocker-dns-attrleaf-05"
ipr="trust200902">
<front>
<title>DNS Scoped Data Through Attribute Leaves</title>
<author
fullname="Dave Crocker"
initials="D."
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city> <region>CA</region> <code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
<uri>http://bbiw.net/</uri>
</address>
</author>
<date
year="2011"/>
<!-- <area>Operations</area> -->
<!-- <workgroup>DNSOP</workgroup> -->
<keyword>DNS</keyword>
<keyword>Domain Name System> </keyword>
<abstract>
<t>Historically, any DNS RR may occur for any domain name. Recent
additions have defined DNS leaf nodes that contain a reserved node
name, beginning with an underscore. The underscore construct is
used to define a semantic scope for DNS records associated with
the parent domain. This note explores the nature of this DNS usage
and defines the "underscore names" registry with IANA. </t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t>The core DNS technical specifications assign no semantics to
domain names or their parts, and no constraints upon which
resource records (RRs) may be associated with particular names.
Over time, some leaf node names, such as "www" and "ftp" have come
to imply support for particular services, but this is a matter of
operational convention, rather than defined protocol
semantics<!-- and the conventions do not probhibit
having those services available under other name-->.
This freedom in the basic technology has permitted a wide range of
administrative and semantic policies to be used -- in parallel.
Data semantics have been limited to the specification of
particular resource records, on the expectation that new ones
would be added as needed. </t>
<t>Some recent service enhancements have defined a restricted scope
for the occurrence of particular resource records. That scope is a
leaf node, within which the uses of specific resource records can
be formally defined and constrained. The leaf has a distinguished
naming convention: It uses a reserved DNS node name that begins
with an underscore. Because host names are not allowed to use the
underscore character, this distinguishes the name from all legal
host name. Effectively, this convention creates a space for
attributes that are associated with the parent domain, one level
up.</t>
<t>An established example is the SRV record <xref
target="RFC2782"/> which generalizes concepts long-used for
email routing by the MX record <xref
target="RFC0974"/><xref
target="RFC2821"/>. The use of special DNS names has
significant benefits and detriments. Some of these are explored in <xref
target="RFC5507"/>.<list
style="hanging">
<t
hangText="[Comment]: ">The terms "resolution context" and
"scoping rules" have been suggested, in place of "semantic
scope". In order to avoid concern for matters of semantics,
this specification uses the term "scoping rules", to create
a focus on the mechanics being defined, rather than nuances
of interpretation for the mechanism.</t>
</list>
</t>
<t>The scoping feature is particularly useful when generalized
resource records are used -- notably TXT and SRV. It provides
efficient separation of one use of them from another. Absent this
separation, an undifferentiated mass of these RRs are returned to
the client which then must parse through the internals of the
records in the hope of finding ones that are relevant. With
underscore-based scoping, only the relevant RRs are returns.</t>
<t>This specification discusses the underscore "attribute"
enhancement, provides an explicit definition of it, and
establishes an IANA registry for the reserved names that begin
with underscore. <list
style="hanging">
<t
hangText="Discussion Venue: ">Discussion about this draft
is directed to the <eref
target="mailto:dnsop@lists.uoregon.edu">dnsop@lists.uoregon.edu</eref>
mailing list of the <eref
target="http://ietf.org/html.charters/dnsop-charter.html">IETF
DNSOP Working Group</eref>.</t>
</list>
</t>
</section>
<section
title="Scaling Benefits and TXT and SRV Resource Records">
<t>Some resource records are generic and support a variety of uses.
Each additional use defines its own rules and, possibly, its own
internal syntax and node-naming conventions to distinguish among
particular types. The TXT and SRV records are the notable
examples. Used freely, some of these approaches scale poorly,
particularly when the same RR can be present in the same leaf
node, but with different uses. An increasingly-popular approach,
with excellent scaling properties, uses an underscore-based name
to a define place in the DNS that is constrained to particular
uses for particular RRs. This means that a direct lookup produces
only the desired records, at no greater cost than a typical
lookup.</t>
<t> In the case of TXT records, different uses have developed largely
without coordination. One side-effect is that there is no
consistently distinguishable internal syntax for the record; even
internal inspection might not be a reliable means of
distinguishing among the different uses. Underscore-based names
therefore provide an administrative way of separating TXT records
that might have different uses, but otherwise would have no
syntactic markers for distinguishing among them. </t>
<t>In the case of the SRV RR distinguishing among different types of
use was part of the design. <xref
target="RFC2782"/> The SRV specification serves as a template,
defining an RR that may only be used for specific applications
when there is an additional specification. The template definition
includes reference to tables of names from which underscore-names
should be drawn. The set of <service> names is defined in
terms of other IANA tables, namely any table with symbolic names.
The other SRV naming field is <proto>, although its pool of
names is not explicitly defined.</t>
</section>
<section
anchor="underfun"
title="Underscore DNS
Registry Function">
<t>This specification defines a registry for DNS nodes names, used to
define scope of use for specific resource records (RR). A given
name defines a specific, constrained context for the use of such
records. This does not constrain the use of other resource records
that are not specified. The purpose of the registry is to avoid
collisions resulting from the use of the same underscore name, for
different applications. </t>
<t>Structurally, the registry is defined as a single, flat table of
names that begin with underscore. In some cases, such as for SRV,
an underscore name might be multi-part, as a sequence of names.
Semantically, this is a hierarchical model, thereby making a flat
registry unexpected.</t>
<t>The registry requires such hierarchies to be registered as a
combinatorial case analysis set, with each entry being a full
sequence of underscore names. Given a scheme that is actually
structured, this flat design is inelegant. However it has the
benefit of being extremely simple, with the added advantage of
being easier for readers to understand, as long as these cases are
small and few.</t>
<texttable
title="Example of Underscore Names">
<ttcol
align="left">NAME</ttcol>
<c>_service1</c>
<c>_service2._protoB</c>
<c>_service3._protoC</c>
<c>_service3._protoC</c>
<c>_service4._protoD._useX</c>
<c>_protoE._region._authority</c>
</texttable>
<t>The flat registry design: <list
style="symbols">
<t>provides significantly simpler administration than is needed
for hierarchical tables, simples, and</t>
<t>is significantly simpler for readers to understand and is
likely to produce fewer programming or administration
errors.</t>
</list>
</t>
<t/>
</section>
<section
anchor="regdef"
title="DNS Underscore Registry Definition">
<t>A registry entry MUST contain: <list>
<t>
<list
style="hanging">
<t
hangText="Name: ">Specifies a textual name for a
scoped portion of the DNS. The name will usually be
taken from the specification cited in the "Purpose"
column and is intended for use in discussions about
the entry.</t>
<t
hangText="DNS Label(s): ">Specifies a sequence of one
or more underscore names that define a single name
reservation. </t>
<t
hangText="Constraints: ">Specifies any restrictions
on use of the name.</t>
<t
hangText="RR(s): ">Lists the RRs that are defined for
use within this scope.</t>
<t
hangText="References">Lists specifications that define
the records and their use under this Name. </t>
<t
hangText="Purpose: ">Specifies the particular
purpose/use for specific RR(s), defined for use within
the scope of the registered underscore name.</t>
</list>
</t>
</list>
</t>
</section>
<section
title="IANA Considerations">
<t> Per <xref
target="RFC2434"/>, IANA is requested to establish a DNS
Underscore Name Registry, for DNS node names that begin with the
underscore character (_) and have been specified in any published
RFC, or are documented by a specification published by another
standards organization. The contents of each entry are defined in <xref
target="regdef"/>.</t>
<texttable
align="left"
anchor="underscope"
title="DNS Underscore SCOPE Name Registry
(with initial values)">
<ttcol>NAME</ttcol>
<ttcol>DNS LABEL</ttcol>
<ttcol>CONSTRAINTS</ttcol>
<ttcol>RR(s)</ttcol>
<ttcol>REFERENCES</ttcol>
<ttcol>PURPOSE</ttcol>
<!---->
<c>SRV TCP</c>
<c>_srv._tcp</c>
<c/>
<c>SRV</c>
<c>
<xref
target="RFC2782"/>
</c>
<c> SRV template </c>
<!-- -->
<c>SRV UDP</c>
<c>_srv._udp</c>
<c/>
<c>SRV</c>
<c>
<xref
target="RFC2782"/>
</c>
<c> SRV template </c>
<!-- -->
<c>LDAP SRV</c>
<c>_ldap._tcp</c>
<c/>
<c>SRV</c>
<c>
<xref
target="RFC2782"/>
</c>
<c> LDAP server </c>
<!-- -->
<c>SIP TCP</c>
<c>_sip._tcp</c>
<c/>
<c>NAPTR</c>
<c><xref
target="RFC3263"/>, <xref
target="RFC6011"/>
</c>
<c>Locating SIP Servers and UA configuration</c>
<!---->
<c>SIPS TCP</c>
<c>_sips._tcp</c>
<c/>
<c>NAPTR</c>
<c><xref
target="RFC3263"/>, <xref
target="RFC6011"/>
</c>
<c>Locating SIP Servers and UA configuration</c>
<!---->
<c>SIP UDP</c>
<c>_sip._udp</c>
<c/>
<c>SRV</c>
<c>
<xref
target="RFC3263"/>, <xref
target="RFC6011"/>
</c>
<c>Locating SIP servers and UA configuration</c>
<!---->
<c>SPF</c>
<c>_spf</c>
<c/>
<c>TXT</c>
<c>
<xref
target="RFC4408"/>
</c>
<c>Authorized IP addresses for sending mail</c>
<!---->
<c>DKIM</c>
<c>_domainkey</c>
<c/>
<c>TXT</c>
<c><xref
target="RFC4871"/></c>
<c>Public key for verifying DKIM signature.</c>
<c>ADSP</c>
<c>_adsp._domainkey</c>
<c> </c>
<c>TXT</c>
<c><xref
target="RFC5617"/></c>
<c>Published DKIM usage practices</c>
<!-- -->
<!---->
<c>PKI LDAP</c>
<c>_PKIXREP._ldap</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4386"/></c>
<c>LDAP PKI Repository</c>
<!-- -->
<c>PKI HTTP</c>
<c>_PKIXREP._http</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4386"/></c>
<c>HTTP PKI Repository</c>
<!-- -->
<c>PKI OCSP</c>
<c>_PKIXREP._ocsp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4386"/></c>
<c>OCSP PKI Repository</c>
<!-- -->
<c>VBR</c>
<c>_vouch</c>
<c> </c>
<c>TXT</c>
<c><xref
target="RFC5518"/></c>
<c>Vouch-by-refererence domain assertion</c>
<!-- -->
<c>DDDS</c>
<c>--unknown!--</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3404"/></c>
<c>Mapping DDDS query to DNS records</c>
<!-- -->
<c>SOAP BEEP</c>
<c>_soap-beep._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4227"/></c>
<c>SOAP over BEEP lookup, when no port specified</c>
<!-- -->
<c>XMLRPC BEEP</c>
<c>_xmlrpc-beep._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3529"/></c>
<c>Resolve url for XML-RPC using BEEP</c>
<!-- -->
<c>Diameter SCTP</c>
<c>_diameter._sctp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3588"/></c>
<c>Diameter rendezvous over SCTP</c>
<!-- -->
<c>Diameter TCP</c>
<c>_diameter._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3588"/></c>
<c>Diameter rendezvous over TCP</c>
<!-- -->
<c>Tunnel</c>
<c>_tunnel._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3620"/></c>
<c>Finding the appropriate address for tunneling into a particular
domain</c>
<!-- -->
<c>SLP TCP</c>
<c>_slpda._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3832"/></c>
<c>Discovering desired services in given DNS domains</c>
<!-- -->
<c>SLP UDP</c>
<c>_slpda._udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3832"/></c>
<c>Discovering desired services in given DNS domains</c>
<!-- -->
<c>IM</c>
<c>_im</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3861"/></c>
<c>Instant Messaging address resolution</c>
<!-- -->
<c>Pres</c>
<c>_pres</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3861"/></c>
<c>Presence address resolution</c>
<!-- -->
<c>Msg Track</c>
<c>_mtqp._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC3887"/></c>
<c>Assist in determining the path that a particular message has
taken through a messaging system</c>
<!-- -->
<c>XMPP Client</c>
<c>_xmpp-client._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC6120"/></c>
<c>XMPP client lookup of server</c>
<!-- -->
<c>XMPP Server</c>
<c>_xmpp-server._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC6120"/></c>
<c>XMPP server-server lookup</c>
<!-- -->
<c>DDDS SRV</c>
<c>_???</c>
<c>(unable to discern details. /dcrocker)</c>
<c>SRV (and NAPTR?)</c>
<c><xref
target="RFC3958"/></c>
<c>Map domain name, application service name, and application
protocol dynamically to target server and port</c>
<!-- -->
<c>Kerberos TCP</c>
<c>_kerberos._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4120"/></c>
<c>purpose</c>
<!-- -->
<c>Kerberos UDP</c>
<c>_kerberos._udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4120"/></c>
<c>purpose</c>
<!-- -->
<c>PKI LDAP</c>
<c>_pkixrep._ldap</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4386"/></c>
<c>Enables certificate-using systems to locate PKI
repositories</c>
<!-- -->
<c>PKI HTTP</c>
<c>_pkixrep._http</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4386"/></c>
<c>Enables certificate-using systems to locate PKI
repositories</c>
<!-- -->
<c>PKI OCSP</c>
<c>_pkixrep._ocsp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4386"/></c>
<c>Enables certificate-using systems to locate PKI
repositories</c>
<!-- -->
<c>Cert Store</c>
<c>_certificates._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4387"/></c>
<c>Obtain certificates and certificate revocation lists (CRLs)
from PKI repositories</c>
<!-- -->
<c>Cert Revocation Store</c>
<c>_crls._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4387"/></c>
<c>Obtain certificates and certificate revocation lists (CRLs)
from PKI repositories</c>
<!-- -->
<c>PGP Key Store</c>
<c>pgpkeys._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4387"/></c>
<c>Obtain certificates and certificate revocation lists (CRLs)
from PKI repositories</c>
<!-- -->
<c>MSRP Relay Locator</c>
<c>_msrp._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC4976"/></c>
<c>purpose</c>
<!-- -->
<c>Mobile IPv6 Bootstrap</c>
<c>_mip6._ipv6</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5026"/>, <xref
target="RFC5555"/></c>
<c>Bootstrap Mobile IPv6 Home Agent information from
non-topological information</c>
<!-- -->
<c>Digital Video Broadcasting TCP</c>
<c>_dvbservdsc._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5328"/></c>
<c>Discover non-default DVB entry points addresses</c>
<!-- -->
<c>Digital Video Broadcasting UDP</c>
<c>_dvbservdsc._udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5328"/></c>
<c>Discover non-default DVB entry points addresses</c>
<!-- -->
<c>CAPWAP AC</c>
<c>_capwap-control._udp</c>
<c/>
<c>rrs</c>
<c><xref
target="RFC5415"/></c>
<c>Discover the CAPWAP AC address(es)</c>
<!-- -->
<c>IM SIP</c>
<c>_im._sip</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5509"/></c>
<c>For resolving Instant Messaging and Presence services with
SIP</c>
<!-- -->
<c>Pres SIP</c>
<c>_pres._sip</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5509"/></c>
<c>For resolving Instant Messaging and Presence services with
SIP</c>
<!-- -->
<c>IEEE 802.21 Mobility TCP</c>
<c>_mihis._tcp</c>
<c/>
<c>NAPTR, SRV</c>
<c><xref
target="RFC5679"/></c>
<c>Discovering servers that provide IEEE 802.21-defined Mobility
Services</c>
<!-- -->
<c>IEEE 802.21 Mobility UDP</c>
<c>_mihis._udp</c>
<c/>
<c>NAPTR, SRV</c>
<c><xref
target="RFC5679"/></c>
<c>Discovering servers that provide IEEE 802.21-defined Mobility
Services</c>
<!-- -->
<c>STUN Client/Server TCP</c>
<c>_stun._.tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5389"/></c>
<c>Find a STUN server</c>
<!-- -->
<c>STUN Client/Server UDP</c>
<c>_stun._.udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5389"/></c>
<c>Find a STUN server</c>
<!-- -->
<c>STUN Client/Server TLS</c>
<c>_stuns._.tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5389"/></c>
<c>Find a STUN server</c>
<!-- -->
<c>TURN TCP</c>
<c>_turn._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5766"/>, <xref
target="RFC5928"/></c>
<c>Control the operation of a relay to bypass NAT</c>
<!-- -->
<c>TURN UDP</c>
<c>_turn._udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5766"/>, <xref
target="RFC5928"/></c>
<c>Control the operation of a relay to bypass NAT</c>
<!-- -->
<c>TURN TLS</c>
<c>_turns._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5766"/>, <xref
target="RFC5928"/></c>
<c>Control the operation of a relay to bypass NAT</c>
<!-- -->
<c>STUN NAT Behavior Discovery TCP</c>
<c>_stun-behavior._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5780"/></c>
<c>Discover the presence and current behavior of NATs and
firewalls between the STUN client and the STUN server</c>
<!-- -->
<c>STUN NAT Behavior Discovery UDP</c>
<c>_stun-behavior._udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5780"/></c>
<c>Discover the presence and current behavior of NATs and
firewalls between the STUN client and the STUN server</c>
<!-- -->
<c>STUN NAT Behavior Discovery TLS</c>
<c>_stun-behaviors._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5780"/></c>
<c>Discover the presence and current behavior of NATs and
firewalls between the STUN client and the STUN server</c>
<!-- -->
<c>Sieve Management</c>
<c>_sieve._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5804"/></c>
<c>Manage Sieve scripts on a remote server</c>
<!-- -->
<c>AFS VLDB</c>
<c>_afs3-vlserver._udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5864"/></c>
<c>Locate services for the AFS distributed file system</c>
<!-- -->
<c>AFS PTS</c>
<c>_afs3-prserver._udp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC5864"/></c>
<c>Locate services for the AFS distributed file system</c>
<!-- -->
<c>Mail MSA Submission</c>
<c>_submission._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC6186"/></c>
<c>Locate email services</c>
<!-- -->
<c>IMAP</c>
<c>_imap._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC6186"/></c>
<c>Locate email services</c>
<!-- -->
<c>IMAP TLS</c>
<c>_imaps._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC6186"/></c>
<c>Locate email services</c>
<!-- -->
<c>POP</c>
<c>_pop3._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC6186"/></c>
<c>Locate email services</c>
<!-- -->
<c>POP TLS</c>
<c>_pop3s._tcp</c>
<c/>
<c>SRV</c>
<c><xref
target="RFC6186"/></c>
<c>Locate email services</c>
<!-- -->
<!-- Table entry template
<c>name</c>
<c>_label</c>
<c>constraints</c>
<c>_</c>
<c><xref
target="" /></c>
<c>purpose</c>
<!-\- -\->
-->
</texttable>
</section>
<section
title="Related Registries">
<t>Numerous specifications have defined their own, independent
registries for use of underscore names. It is likely that adoption
of the proposed, integrated registry should render these piecemeal
registries obsolete</t>
<t>Registries that are candidates for replacement include: <list>
<t>Instant Messaging SRV Protocol Label Registry</t>
<t>Public Key Infrastructure using X.509 (PKIX) Parameters</t>
<t>Presence SRV Protocol Label Registry</t>
</list>
</t>
</section>
<section
title="Security Considerations">
<t>This memo raises no security issues.</t>
</section>
</middle>
<back>
<references
title="Normative References">
<reference
anchor="RFC2434">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author
fullname="T. Narten"
initials="T."
surname="Narten">
<organization>IBM</organization>
</author>
<author
fullname="H. Alvestrand"
initials="H."
surname="Alvestrand">
<organization>Maxware</organization>
</author>
<date
month="October"
year="1998"/>
</front>
<seriesInfo
name="RFC"
value="2434"/>
</reference>
</references>
<references
title="References -- Informative">
<reference
anchor="RFC2821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author
fullname="J. Klensin"
initials="J."
surname="Klensin">
<organization/>
</author>
<date
month="April"
year="2001"/>
<abstract>
<t>This document is a self-contained specification of the
basic protocol for the Internet electronic mail
transport. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="2821"/>
<format
octets="192504"
target="http://www.rfc-editor.org/rfc/rfc2821.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC0974">
<front>
<title>Mail routing and the domain system</title>
<author
fullname="Craig Partridge"
initials="C."
surname="Partridge">
<organization>Bolt Baranek and Newman (BBN) Laboratories
Inc., CSNET CIC</organization>
</author>
<date
day="1"
month="January"
year="1986"/>
</front>
<seriesInfo
name="RFC"
value="974"/>
<format
octets="18581"
target="http://www.rfc-editor.org/rfc/rfc974.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC2782">
<front>
<title
abbrev="DNS SRV RR">A DNS RR for specifying the location of
services (DNS SRV)</title>
<author
fullname="Arnt Gulbrandsen"
initials="A."
surname="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
fullname="Paul Vixie"
initials="P."
surname="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
fullname="Levon Esibov"
initials="L."
surname="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
month="February"
year="2000"/>
<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
octets="24013"
target="http://www.rfc-editor.org/rfc/rfc2782.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC3263">
<front>
<title>Session Initiation Protocol (SIP): Locating SIP
Servers</title>
<author
fullname="J. Rosenberg"
initials="J."
surname="Rosenberg">
<organization/>
</author>
<author
fullname="H. Schulzrinne"
initials="H."
surname="Schulzrinne">
<organization/>
</author>
<date
month="June"
year="2002"/>
<abstract>
<t>The Session Initiation Protocol (SIP) uses DNS procedures
to allow a client to resolve a SIP Uniform Resource
Identifier (URI) into the IP address, port, and transport
protocol of the next hop to contact. It also uses DNS to
allow a server to send a response to a backup client if
the primary client has failed. This document describes
those DNS procedures in detail. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="3263"/>
<format
octets="42310"
target="http://www.rfc-editor.org/rfc/rfc3263.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC3404">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Four:
The Uniform Resource Identifiers (URI) Resolution
Application</title>
<author
fullname="M. Mealling"
initials="M."
surname="MMealling"/>
<date
month="October"
year="2002"/>
</front>
<seriesInfo
name="RFC"
value="3404"/>
</reference>
<reference
anchor="RFC3529">
<front>
<title>Using Extensible Markup Language-Remote Procedure
Calling (XML-RPC) in Blocks Extensible Exchange Protocol
(BEEP) </title>
<author
fullname="W. Harold"
initials="W"
surname="Harold">
<organization>IBM</organization>
</author>
<date
month="April"
year="2003"/>
</front>
<seriesInfo
name="RFC"
value="3529"/>
</reference>
<reference
anchor="RFC3588">
<front>
<title>Diameter Base Protocol </title>
<author
fullname="P. Calhoun"
initials="P."
surname="Calhoun">
<organization>Airespace, Inc.</organization>
</author>
<author
fullname="J. Loughney"
initials="J."
surname="Loughney">
<organization>Nokia</organization>
</author>
<author
fullname="E. Guttman"
initials="E."
surname="Guttman">
<organization>Sun Microsystems, Inc.</organization>
</author>
<author
fullname="G. Zorn"
initials="G."
surname="Zorn">
<organization>Cisco Systems, Inc</organization>
</author>
<author
fullname="J. Arkko"
initials="J."
surname="Arkko">
<organization>Ericsson</organization>
</author>
<date
month="September"
year="2003"/>
</front>
</reference>
<reference
anchor="RFC3620">
<front>
<title>The TUNNEL Profile</title>
<author
fullname="D. New"
initials="D."
surname="New"/>
<date
month="October"
year="2003"/>
</front>
<seriesInfo
name="RFC"
value="3620"/>
</reference>
<reference
anchor="RFC3861">
<front>
<title>Address Resolution for Instant Messaging and
Presence</title>
<author
fullname="J. Peterson"
initials="J."
surname="Peterson">
<organization>Neustar</organization>
</author>
<date
month="August"
year="2004"/>
</front>
<seriesInfo
name="RFC"
value="3861"/>
</reference>
<reference
anchor="RFC3832">
<front>
<title>Remote Service Discovery in the Service Location
Protocol (SLP) via DNS SRV</title>
<author
fullname="W. Zhao"
initials=""
surname="">
<organization>Columbia University</organization>
</author>
<author
fullname="H. Schulzrinne"
initials=""
surname="">
<organization>Columbia University</organization>
</author>
<author
fullname="E. Guttman"
initials=""
surname="">
<organization>Sun Microsystems</organization>
</author>
<author
fullname="C. Bisdikian"
initials=""
surname="">
<organization>IBM</organization>
</author>
<author
fullname="W. Jerome"
initials=""
surname="">
<organization>IBM</organization>
</author>
<date
month="July"
year="2004"/>
</front>
</reference>
<reference
anchor="RFC3887">
<front>
<title>Message Tracking Query Protocol</title>
<author/>
<date
month="September"
year="2007"/>
</front>
</reference>
<reference
anchor="RFC3958">
<front>
<title>Domain-Based Application Service Location Using SRV RRs
and the Dynamic Delegation Discovery Service (DDDS)</title>
<author
fullname="L. Daigle"
initials="L."
surname="Daigle">
<organization>VeriSign, Inc.</organization>
</author>
<author
fullname="A. Newton"
initials="A."
surname="Newton">
<organization>VeriSign, Inc.</organization>
</author>
<date
month="January"
year="2005"/>
</front>
<seriesInfo
name="RFC"
value="3958"/>
</reference>
<reference
anchor="RFC4120">
<front>
<title>The Kerberos Network Authentication Service (V5)</title>
<author
fullname="C. Neuman"
initials=""
surname="">
<organization>USC-ISI</organization>
</author>
<author
fullname="T. Yu"
initials=""
surname="">
<organization>MIT</organization>
</author>
<author
fullname="S. Hartman"
initials=""
surname="">
<organization>MIT</organization>
</author>
<author
fullname="K. Raeburn"
initials=""
surname="">
<organization>MIT</organization>
</author>
<date
month="July"
year="2005"/>
</front>
<seriesInfo
name="RFC"
value="4120"/>
</reference>
<reference
anchor="RFC4227">
<front>
<title>Using the Simple Object Access Protocol (SOAP) in Blocks
Extensible Exchange Protocol (BEEP)</title>
<author
fullname="E. O'Tuathail"
initials="E."
surname="O'Tuathail">
<organization>Clipcode.com</organization>
</author>
<author
fullname="M. Rose"
initials="M."
surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>
</author>
<date
month="January"
year="2006"/>
</front>
<seriesInfo
name="RFC"
value="4227"/>
</reference>
<reference
anchor="RFC4386">
<front>
<title>Internet X.509 Public Key Infrastructure: Repository
Locator Service</title>
<author
fullname="S. Boeyen"
initials="S."
surname="Boeyen">
<organization>Entrust Inc.</organization>
</author>
<author
fullname="P. Hallam-Baker"
initials="P."
surname="Hallam-Baker">
<organization>VeriSign Inc.</organization>
</author>
<date
month="February"
year="2006"/>
</front>
</reference>
<reference
anchor="RFC4387">
<front>
<title>Internet X.509 Public Key Infrastructure Operational
Protocols: Certificate Store Access via HTTP</title>
<author
fullname="P. Gutmann"
initials="P."
role="editor"
surname="Gutmann">
<organization>University of Auckland</organization>
</author>
<date
month="February"
year="2006"/>
</front>
<seriesInfo
name="RFC"
value="4387"/>
</reference>
<reference
anchor="RFC4408">
<front>
<title>Sender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1</title>
<author
fullname="M. Wong"
initials="M."
surname="Wong">
<organization/>
</author>
<author
fullname="W. Schlitt"
initials="W."
surname="Schlitt">
<organization/>
</author>
<date
month="April"
year="2006"/>
<abstract>
<t>E-mail on the Internet can be forged in a number of ways.
In particular, existing protocols place no restriction on
what a sending host can use as the reverse-path of a
message or the domain given on the SMTP HELO/EHLO
commands. This document describes version 1 of the ender
Policy Framework (SPF) protocol, whereby a domain may
explicitly authorize the hosts that are allowed to use
its domain name, and a receiving host may check such
authorization. This memo defines an Experimental Protocol
for the Internet community.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4408"/>
<format
octets="105009"
target="http://www.rfc-editor.org/rfc/rfc4408.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC5617">
<front>
<title>DomainKeys Identified Mail (DKIM) Author Domain Signing
Practices (ADSP)</title>
<author
fullname="E. Allman"
initials=""
surname="">
<organization>Sendmail, Inc.</organization>
</author>
<author
fullname="J. Fenton"
initials=""
surname="">
<organization>Cisco Systems, Inc.</organization>
</author>
<author
fullname="M. Delany"
initials=""
surname="">
<organization>Yahoo! Inc.</organization>
</author>
<author
fullname="J. Levine"
initials=""
surname="">
<organization>Taughannock Networks</organization>
</author>
<date
month="August"
year="2009"/>
</front>
</reference>
<reference
anchor="RFC4871">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author
fullname="E. Allman"
initials="E."
surname="Allman">
<organization/>
</author>
<author
fullname="J. Callas"
initials="J."
surname="Callas">
<organization/>
</author>
<author
fullname="M. Delany"
initials="M."
surname="Delany">
<organization/>
</author>
<author
fullname="M. Libbey"
initials="M."
surname="Libbey">
<organization/>
</author>
<author
fullname="J. Fenton"
initials="J."
surname="Fenton">
<organization/>
</author>
<author
fullname="M. Thomas"
initials="M."
surname="Thomas">
<organization/>
</author>
<date
month="May"
year="2007"/>
<abstract>
<t>DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key
cryptography and key server technology to permit
verification of the source and contents of messages by
either Mail Transfer Agents (MTAs) or Mail User Agents
(MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message,
thus protecting message signer identity and the integrity
of the messages they convey while retaining the
functionality of Internet email as it is known today.
Protection of email identity may assist in the global
control of "spam" and "phishing". [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4871"/>
<format
octets="166054"
target="http://www.rfc-editor.org/rfc/rfc4871.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC4976">
<front>
<title>Relay Extensions for the Message Session Relay Protocol
(MSRP)</title>
<author
fullname="C. Jennings"
initials="C."
surname="Jennings">
<organization>Cisco Systems, Inc.</organization>
</author>
<author
fullname="R. Mahy"
initials="R."
surname="Mahy">
<organization>Plantronics</organization>
</author>
<author
fullname="A. B. Roach"
initials=""
surname="Roach">
<organization>Estacado Systems</organization>
</author>
<date
month="September"
year="2007"/>
</front>
<seriesInfo
name="RFC"
value="4976"/>
</reference>
<reference
anchor="RFC5026">
<front>
<title>Mobile IPv6 Bootstrapping in Split Scenario</title>
<author
fullname="G. Giaretta"
initials="G."
role="editor"
surname="Giaretta">
<organization>Qualcomm</organization>
</author>
<author
fullname="J. Kempf"
initials="J."
surname="Kempf">
<organization>DoCoMo Labs USA</organization>
</author>
<author
fullname="V. Devarapalli"
initials="V."
role="editor"
surname="Devarapalli">
<organization>Azaire Networks</organization>
</author>
<date
month="October"
year="2007"/>
</front>
<seriesInfo
name="RFC"
value="5026"/>
</reference>
<reference
anchor="RFC5328">
<front>
<title>A Uniform Resource Name (URN) Namespace for the Digital
Video Broadcasting Project (DVB)</title>
<author
fullname="A. Adolf"
initials="A."
surname="Adolf">
<organization>Micronas GmbH</organization>
</author>
<author
fullname="P. MacAvock"
initials="P."
surname="MacAvock">
<organization>DVB Project</organization>
</author>
<date
month="September"
year="2008"/>
</front>
<seriesInfo
name="RFC"
value="5328"/>
</reference>
<reference
anchor="RFC5389">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author
fullname="J. Rosenberg"
initials=""
surname="Rosenberg">
<organization>Cisco</organization>
</author>
<author
fullname="R. Mahy"
initials=""
surname="Mahy">
<organization>Cisco</organization>
</author>
<author
fullname="P. Matthews"
initials=""
surname="Matthews"/>
<author
fullname="D. Wing"
initials=""
surname="Wing">
<organization>Cisco</organization>
</author>
<date
month="October"
year="2008"/>
</front>
<seriesInfo
name="RFC"
value="5389"/>
</reference>
<reference
anchor="RFC5507">
<front>
<title/>
<author
fullname="P. Faltstrom"
initials="P."
role="editor"
surname="Faltstrom">
<organization>IAB</organization>
</author>
<author
fullname="R. Austein"
initials="R."
role="editor"
surname="Austein">
<organization>IAB</organization>
</author>
<date
month="April"
year="2009"/>
</front>
<seriesInfo
name="RFC"
value="5507"/>
</reference>
<reference
anchor="RFC5415">
<front>
<title>Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification</title>
<author
fullname="P. Calhoun"
initials="P."
role="editor"
surname="Calhoun">
<organization>Cisco Systems, Inc.</organization>
</author>
<author
fullname="M. Montemurro"
initials="M."
role="editor"
surname="Montemurro">
<organization>Research In Motion</organization>
</author>
<author
fullname="D. Stanley"
initials="D."
role="editor"
surname="Stanley">
<organization>Aruba Networks</organization>
</author>
<date
month="March"
year="2009"/>
</front>
<seriesInfo
name="RFC"
value="5415"/>
</reference>
<reference
anchor="RFC5509">
<front>
<title>Internet Assigned Numbers Authority (IANA) Registration
of Instant Messaging and Presence DNS SRV RRs for the
Session Initiation Protocol (SIP)</title>
<author
fullname="S. Loreto"
initials="S."
surname="Loreto">
<organization>Ericsson</organization>
</author>
<date
month="April"
year="2009"/>
</front>
<seriesInfo
name="RFC"
value="5509"/>
</reference>
<reference
anchor="RFC5518">
<front>
<title>Vouch By Reference</title>
<author
fullname="P. Hoffman"
initials="P."
surname="Hoffman">
<organization>Domain Assurance Council</organization>
</author>
<author
fullname="J. Levine"
initials="J."
surname="Levine">
<organization>Domain Assurance Council</organization>
</author>
<author
fullname="A. Hathcock"
initials="A."
surname="Hathcock">
<organization>Alt-N Technologies</organization>
</author>
<date
month="April"
year="2009"/>
</front>
<seriesInfo
name="RFC5"
value="5518"/>
</reference>
<reference
anchor="RFC5555">
<front>
<title>Mobile IPv6 Support for Dual Stack Hosts and
Routers</title>
<author
fullname="H. Soliman"
initials="H."
role="editor"
surname="Soliman">
<organization>Elevate Technologies</organization>
</author>
<date
month="June"
year="2009"/>
</front>
<seriesInfo
name="RFC"
value="5555"/>
</reference>
<reference
anchor="RFC5679">
<front>
<title>Locating IEEE 802.21 Mobility Services Using DNS</title>
<author
fullname="G. Bajko"
initials="G."
surname="Bajko"/>
<date
month="December"
year="2009"/>
</front>
<seriesInfo
name="RFC"
value="5679"/>
</reference>
<reference
anchor="RFC5766">
<front>
<title>Traversal Using Relays around NAT (TURN): Relay
Extensions to Session Traversal Utilities for NAT
(STUN)</title>
<author
fullname="R. Mahy"
initials="R."
surname="Mahy"/>
<author
fullname="P. Matthews"
initials="P."
surname="Matthews">
<organization>Alcatel-Lucent</organization>
</author>
<author
fullname="J. Rosenberg"
initials="J."
surname="Rosenberg">
<organization>jdrosen.net</organization>
</author>
<date
month="April"
year="2010"/>
</front>
<seriesInfo
name="RFC"
value="5766"/>
</reference>
<reference
anchor="RFC5780">
<front>
<title>NAT Behavior Discovery Using Session Traversal Utilities
for NAT (STUN)</title>
<author
fullname="D. MacDonald"
initials="D."
surname="MacDonald">
<organization>Skype</organization>
</author>
<author
fullname="B. Lowekamp"
initials="B."
surname="Lowekamp">
<organization>Skype</organization>
</author>
<date
month="May"
year="2010"/>
</front>
<seriesInfo
name="RFC"
value="5780"/>
</reference>
<reference
anchor="RFC5804">
<front>
<title>A Protocol for Remotely Managing Sieve Scripts</title>
<author
fullname="A. Melnikov"
initials="A."
role="editor"
surname="Melnikov">
<organization>Isode Limited</organization>
</author>
<author
fullname="T. Martin"
initials="T."
surname="Martin">
<organization>BeThereBeSquare, Inc.</organization>
</author>
<date
month="July"
year="2010"/>
</front>
<seriesInfo
name="RFC"
value="5804"/>
</reference>
<reference
anchor="RFC5864">
<front>
<title>NS SRV Resource Records for AFS</title>
<author
fullname="R. Allbery"
initials="R."
surname="Allbery">
<organization>Stanford University</organization>
</author>
<date
month="April"
year="2010"/>
</front>
<seriesInfo
name="RFC"
value="5864"/>
</reference>
<reference
anchor="RFC5928">
<front>
<title>Traversal Using Relays around NAT (TURN) Resolution
Mechanism</title>
<author
fullname="M. Petit-Huguenin"
initials="M."
surname="Petit-Huguenin"/>
<date
month="August"
year="2010"/>
</front>
<seriesInfo
name="RFC"
value="5928"/>
</reference>
<reference
anchor="RFC6011">
<front>
<title>Session Initiation Protocol (SIP) User Agent
Configuration</title>
<author
fullname="S. Lawrence"
initials="S."
role="editor"
surname="Lawrence">
<organization>Linden Research, Inc.</organization>
</author>
<author
fullname="J. Elwell"
initials="J."
surname="Elwell">
<organization>Siemens Enterprise
Communications</organization>
</author>
<date
month="October"
year="2010"/>
</front>
<seriesInfo
name="RFC"
value="6011"/>
</reference>
<reference
anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP):
Core</title>
<author
fullname="P. Saint-Andre"
initials="P."
surname="Saint-Andre">
<organization>Cisco</organization>
</author>
<date
month="March"
year="2011"/>
</front>
<seriesInfo
name="RFC"
value="6120"/>
</reference>
<reference
anchor="RFC6186">
<front>
<title>Use of SRV Records for Locating Email Submission/Access
Services</title>
<author
fullname="C. Daboo"
initials="C."
surname="Daboo">
<organization>Apple Inc.</organization>
</author>
<date
month="March"
year="2011"/>
</front>
<seriesInfo
name="RFC"
value="6186"/>
</reference>
</references>
<section
title="Acknowledgements">
<t>Thanks go to Bill Fenner, Tony Hansen, Peter Koch, Olaf Kolkman,
and Andrew Sullivan for diligent review of the earlier drafts.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:37 |