use of S-NAPTR offers the following:
1. A means by which an operator can split the set of servers running
REGA from the set of servers running REGB. This is to say, the
operator is able to split out the set of servers serving up data
for REGA from the set of servers serving up data for REGB.
2. A means by which an operator can distinguish the set of servers
running iris-a from the set of servers running iris-b. This is to
say, the operator is able to split out the set of servers running
protocol iris-a serving REGA and REGB data from the set of servers
running protocol iris-b serving REGA and REGB data.
3. A means by which an operator can specify which set of the servers
to operate and which set of the above servers to delegate to
another operator.
To implement the first feature, the operator deploys the following in
his or her DNS zone:
example.com.
;; order pref flags service re replacement
IN NAPTR 100 10 "" "REGA:iris-a:iris-b" "" rega.example.com
IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" regb.example.com
To implement the second feature, the operator then adds the following
in their DNS zone:
rega.example.com.
;; order pref flags service re replacement
IN NAPTR 100 10 "s" "REGA:iris-a" "" _iris-a._udp.example.com
regb.example.com.
IN NAPTR 100 10 "s" "REGA:iris-b" "" _iris-b._tcp.example.com
_iris-a._udp.example.com.
;; pref weight port target
IN SRV 10 0 34 big-a.example.com.
IN SRV 20 0 34 small-a.example.com.
_iris-b._tcp.example.com.
;; pref weight port target
IN SRV 10 0 34 big-b.example.com.
IN SRV 20 0 34 small-b.example.com.
Finally, an operator may decide to operate the REGA services while
delegating the REGB services to somebody else. Here is how that is
done:
example.com.
;; order pref flags service re replacement
IN NAPTR 100 10 "" "REGA:iris-a:iris-b" "" rega.example.com
IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" somebodyelse.com
Or the operator may decide to operate REGB services under the iris-a
protocol/transport while delegating the REGB services under the
iris-b protocol/transport to somebody else.
example.com.
;; order pref flags service re replacement
IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" regb.example.com
IN NAPTR 100 10 "s" "REGB:iris-a" "" _iris-a._udp.example.com
IN NAPTR 100 10 "s" "REGB:iris-b" "" _iris-b._tcp.somebodyelse.com
_iris-a._udp.example.com.
;; pref weight port target
IN SRV 10 0 34 big-a.example.com.
IN SRV 20 0 34 small-a.example.com.
Note that while this last example is possible, it is probably not
advisable because of the operational issues involved in synchronizing
the data between example.com and somebodyelse.com. It is provided
here as an example of what is possible.
A.2. Using S-NAPTR for Cohabitation
Given the examples in Appendix A.1, the use of S-NAPTR could be part
of a transition strategy for cohabitation of protocols solving the
problems of CRISP [17].
For example, the type of data for domain information could be given
the application service label of "DREG1". Given this, the service
field of an S-NAPTR compliant NAPTR record could read
"DREG1:whois:iris-beep"
This service field conveys that domain data, as defined by CRISP, is
available via both the iris-beep protocol and the whois protocol.
The whois application protocol label refers to RFC 954 [19].
Appendix B. IRIS Design Philosophy
Beyond the concrete arguments that could be placed behind a
thoughtful analysis of the bits flying across the ether, there are
other abstract reasons for the development of IRIS. This section
attempts an explanation.
B.1. The Basic Premise
IRIS has been designed as a directory service for public-facing
registries of Internet resources. The basic premise is this:
o A client should be able to look up any single piece of data from
any type of registry. This lookup should involve a straight-
forward and consistent definition for finding the registry and
should entail a hit to a single data index in the registry.
o Anything more, such as searches up and down the DNS tree to find
the registry or searches across multiple indexes in a registry,
requires a client with special knowledge of the data relationships
contained within a registry.
Therefore, IRIS does the following:
o It specifies the basic schema language used by all registries to
specify their schemas.
o It provides the basic framework for a registry to make a
reference to an entity in another type of registry.
And, therefore, IRIS does not do the following:
o It does not specify a common query language across all types of
registries. A common query language imposed across multiple types
of registries usually results in the disabling of certain
functions by a server operator in order to meet acceptable levels
of performance, leaving a common query language that does not
commonly work.
o It does not impose any relationship between sets of data in any
type of registry, such as specifying a tree. There are many types
of Internet resources, and they do not all share the same style of
relationship with their contained sets of data. When it is not a
natural fit, an imposition of a common relationship is often a
concern and not a benefit.
B.2. The Lure of a Universal Client
The design premise of IRIS signifies that, for directory services,
there is no such thing as a universal client (or that if there is
one, it is commonly called the "web browser").
For IRIS, the closest thing to a universal client is one that may
"look up" data and may be able to display the data in a rudimentary
fashion. For a client to be able to "search" data or display it in a
truly user-friendly manner, it must have specific knowledge about the
type of data it is retrieving.
Attempts to outfit a universal client with a common query language
are also not very useful. A common query language may be applied to
a specific problem domain, which would require a user to have
expertise in both the common query language and the problem domain.
In the end, the outcome is usually the development of a client
specific to the problem domain but saddled with translation of the
user’s desires and the lowest-common-denominator aspect of the query
language.
B.3. Server Considerations
As mentioned above, IRIS was designed for the directory service needs
of public-facing registries. In this light, certain aspects of more
generalized directory services are a hindrance in an environment that
does not have the same control and safety considerations as a managed
network.
For instance, a common query language can provide great flexibility
to both the power user and the abusive user. An abusive user could
easily submit a query across multiple indexes with partial values.
Such a query would have no utility other than to cause denial of
service to other users. To combat this, a service operator must
restrict the types of queries that cause harm to overall performance,
and this act obsoletes the benefit of a common query language.
Another consideration for server performance is the lack of a
required data relationship. Because sets of data often have
differing relationships, a one-size-fits-all approach does not fit
well with all types of registries. In addition, public-facing
services tend to have service level requirements that cannot
reasonably be met by transforming complete data stores from a native
format into a format enforcing an artificial set of relationships.
To combat these issues, operators of public-facing services tend to
create their own custom query parsers and back-end data stores. But
doing so brings into question the use of a generalized directory
service.
Finally, IRIS is built upon a set of standard technological layers.
This allows service operators to switch components to meet the needs
of their particular environment.
B.4. Lookups, Searches, and Entity Classes
IRIS supports both lookups and searches. Conceptually, the
difference between the two is as follows:
A "lookup" is a single query with a discrete value on a single
index.
Anything more, such as partial value queries, queries across
multiple indexes, or multiple queries to a single index is a
"search".
Lookups are accomplished through the defined query <lookupEntity>.
This query specifies a discrete name, called the entity name, to be
queried in a single index, called the entity class. Therefore,
implementations may consider a type of registry to be composed of
multiple indexes, one for each defined entity class.
There are no standard searches in IRIS. Each type of registry
defines its own set of searches.
B.5. Entities References, Search Continuations, and Scope
Due to its effect on client behavior and the side effects such
behavior may have on servers, IRIS makes a clear distinction between
entity references (<entity>) and search continuations
(<searchContinuation>). It is not an add-on, but a fundamental core
of the protocol.
The distinction is very important to a client:
"Go look over there and you will find what you seek." "Go look
over there and you may find what you seek, or you may find some
other stuff, or you may find nothing."
Finally, because IRIS makes no assumptions about and places no
requirements on the relationship of data in a registry, this also
extends to data of the same registry type spread across multiple
authority areas. This means that IRIS makes no requirements as to
the scope of entity references or search continuations. The scope is
determined by what the registry type needs and by what the registry
type allows a service operator.
Appendix C. Acknowledgments
The terminology used in this document to describe namespaces and
namespaces of namespaces is now much clearer thanks to the skillful
debate tactics of Leslie Daigle. Previously, it was much more
confusing. In addition, Leslie has provided great insight into the
details of URIs, URNs, and NAPTR/SRV resource records.
Many other technical complexities were proved unnecessary by David
Blacka and have been removed. And his IRIS implementation has helped
smooth out the rougher edges.
Authors’ Addresses
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/
Marcos Sanz
DENIC eG
Wiesenhuettenplatz 26
D-60329 Frankfurt
Germany
EMail: sanz@denic.de
URI: http://www.denic.de/
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.