One document matched: draft-crocker-dns-attrleaf-07.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-07" ipr="trust200902"
updates="lots of rfc, to be listed">
<front>
<title abbrev="DNS AttrLeaf">DNS Scoped Data Through '_Underscore'
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="2015"/>
<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 that are associated with
the parent domain. This specification 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) are permitted to 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>As an alternative to defining new RRs, some DNS service enhancements
have specified 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 a "host" domain name is not
allowed to use the underscore character, this distinguishes the name
from all legal host names.<xref target="RFC1035"/> 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 is returned to the DNS client,
which then must parse through the internals of the records in the
hope of finding ones that are relevant; in some cases the results
are ambiguous, because the records do not adequately self-identify.
With underscore-based scoping, only the relevant RRs are
returned.</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. It
updates the many existing specifications that have defined
underscore names, in order to aggregate the references to a single
IANA table.<list style="hanging">
<t hangText="Discussion Venue: ">Discussion about this draft is
directed to the <eref target="mailto:we-need-a-list"
>apps-discuss@ietf.org</eref> mailing list.</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, at a defined
place in the DNS tree, so as to constrain to particular uses for
particular RRs farther down the branch using that name. This means
that a direct lookup produces only the desired records, at no
greater cost than a typical DNS 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
the inefficiencies of internal inspection might not provide a
reliable means of distinguishing among the different uses.
Underscore-based names therefore define 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 might 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 creates a registry for DNS nodes names that begin
with an underscore and are 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. Within this scope, use of other
resource records that are not specified is permitted. The purpose of
the Underscore registry is to avoid collisions resulting from the
use of the same underscore-based 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 underscore
names. Semantically, this is a hierarchical model and it is
theoretically reasonable to allow re-use of an underscore name in
different underscore contexts. That is, a subordinate name is
meaningful only within the scope of the first (parent) underscore
name. As such, they can be ignored by this global Underscore
registry. That is, the registry is for the definition of
highest-level underscore node name used.</t>
<texttable title="Example of Underscore Names">
<ttcol align="left">NAME</ttcol>
<c>_service1</c>
<c>_service2._protoB</c>
<c>_service3._protoB</c>
<c>_service3._protoC</c>
<c>_service4._protoD._useX</c>
<c>_protoE._region._authority</c>
</texttable>
<t>Only the left-most names are registered in the IANA table.
Definition and registration of the subordinate names is the
responsibility of the specification that creates the highest-level
(left-most) registry entry.</t>
</section>
<section anchor="regdef" title="DNS Underscore Registry Definition">
<t>A registry entry contains: <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: ">Specifies a single underscore
name that defines a name reservation; this name is the
"global" entry name for the scoped resource records that
are associated with that name. </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>
<t>Initial entriess in the registry are:<list>
<t>{ Enhancement of this table to include all underscore name
reservations in effect at the time this document is published
is left as an exercise to the readers... /d }</t>
</list></t>
<texttable align="left" anchor="underscore"
title="DNS Underscore SCOPE Name Registry (with
initial values)">
<ttcol>NAME</ttcol>
<ttcol>LABEL </ttcol>
<!-- <ttcol>CONSTRAINTS</ttcol>-->
<ttcol>RR</ttcol>
<ttcol>REFERENCE </ttcol>
<ttcol>PURPOSE</ttcol>
<!---->
<c>SRV</c>
<c>_srv</c>
<c>SRV</c>
<c>
<xref target="RFC2782"/>
</c>
<c> SRV template </c>
<!-- -->
<c>LDAP</c>
<c>_ldap</c>
<c>SRV</c>
<c>
<xref target="RFC2782"/>
</c>
<c> LDAP server </c>
<!-- -->
<c>SIP</c>
<c>_sip</c>
<c>NAPTR</c>
<c><xref target="RFC3263"/>
<xref target="RFC6011"/>
</c>
<c>Locating SIP Servers and UA configuration</c>
<!---->
<c>SPF</c>
<c>_spf</c>
<c>TXT</c>
<c>
<xref target="RFC4408"/>
</c>
<c>Authorized IP addresses for sending mail</c>
<!---->
<c>DKIM</c>
<c>_domainkey</c>
<c>TXT</c>
<c>
<xref target="RFC4871"/>
</c>
<c>Public key for verifying DKIM signature.</c>
<c>ADSP</c>
<c>_adsp.</c>
<c>TXT</c>
<c>
<xref target="RFC5617"/>
</c>
<c>Published DKIM usage practices</c>
<!-- -->
<!---->
<c>PKI LDAP</c>
<c>_PKIXREP</c>
<c>SRV</c>
<c>
<xref target="RFC4386"/>
</c>
<c>PKI Repository</c>
<!-- -->
<c>VBR</c>
<c>_vouch</c>
<c>TXT</c>
<c>
<xref target="RFC5518"/>
</c>
<c>Vouch-by-refererence domain assertion</c>
<!-- -->
<c>DDDS</c>
<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</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</c>
<c>SRV</c>
<c>
<xref target="RFC3529"/>
</c>
<c>Resolve url for XML-RPC using BEEP</c>
<!-- -->
<c>Diameter</c>
<c>_diameter</c>
<c>SRV</c>
<c>
<xref target="RFC3588"/>
</c>
<c>Diameter rendezvous</c>
<!-- -->
<c>Tunnel</c>
<c>_tunnel</c>
<c>SRV</c>
<c>
<xref target="RFC3620"/>
</c>
<c>Finding the appropriate address for tunneling into a particular
domain</c>
<!-- -->
<c>SLP</c>
<c>_slpda</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>SRV</c>
<c>
<xref target="RFC3861"/>
</c>
<c>Instant Messaging address resolution</c>
<!-- -->
<c>Pres</c>
<c>_pres</c>
<c>SRV</c>
<c>
<xref target="RFC3861"/>
</c>
<c>Presence address resolution</c>
<!-- -->
<c>Msg Track</c>
<c>_mtqp</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</c>
<c>SRV</c>
<c>
<xref target="RFC6120"/>
</c>
<c>XMPP client lookup of server</c>
<!-- -->
<c>XMPP Server</c>
<c>_xmpp-server</c>
<c>SRV</c>
<c>
<xref target="RFC6120"/>
</c>
<c>XMPP server-server lookup</c>
<!-- -->
<c>DDDS SRV</c>
<c>_???</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</c>
<c>_kerberos</c>
<c>SRV</c>
<c>
<xref target="RFC4120"/>
</c>
<c>purpose</c>
<!-- -->
<c>PKI</c>
<c>_pkixrep</c>
<c>SRV</c>
<c>
<xref target="RFC4386"/>
</c>
<c>Enables certificate-using systems to locate PKI repositories</c>
<!-- -->
<c>Certificates</c>
<c>_certificates</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</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</c>
<c>SRV</c>
<c>
<xref target="RFC4976"/>
</c>
<c>purpose</c>
<!-- -->
<c>Mobile IPv6 Bootstrap</c>
<c>_mip6</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</c>
<c>_dvbservdsc</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</c>
<c>rrs</c>
<c>
<xref target="RFC5415"/>
</c>
<c>Discover the CAPWAP AC address(es)</c>
<!-- -->
<c>IM</c>
<c>_im</c>
<c>SRV</c>
<c>
<xref target="RFC5509"/>
</c>
<c>For resolving Instant Messaging and Presence services with
SIP</c>
<!-- -->
<c>Presence</c>
<c>_pres</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</c>
<c>_mihis</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</c>
<c>_stun</c>
<c>SRV</c>
<c>
<xref target="RFC5389"/>
</c>
<c>Find a STUN server</c>
<!-- -->
<c>TURN</c>
<c>_turn</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</c>
<c>_stun-behavior</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</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</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</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</c>
<c>SRV</c>
<c>
<xref target="RFC6186"/>
</c>
<c>Locate email services</c>
<!-- -->
<c>IMAP</c>
<c>_imap</c>
<c>SRV</c>
<c>
<xref target="RFC6186"/>
</c>
<c>Locate email services</c>
<!-- -->
<c>POP</c>
<c>_pop3</c>
<c>SRV</c>
<c>
<xref target="RFC6186"/>
</c>
<c>Locate email services</c>
<!-- -->
<c>POP TLS</c>
<c>_pop3s</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 and Updated Registries">
<t>
<list>
<t>This section needs to contained details specification of the
updates to existing underscore "registries", in order to have
those specifcations point to this new registry.</t>
</list></t>
<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="RFC1035">
<front>
<title abbrev="Domain Implementation and Specification">Domain
names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P."
surname="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 day="1" month="November" year="1987"/>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<format octets="125626"
target="http://www.rfc-editor.org/rfc/rfc1035.txt" type="TXT"/>
</reference>
<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. Special
thanks to Ray Bellis for nearly 10 years of persistent encouragement
to pursue this document.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:22:32 |