<attribute
name="language"
type="language"
use="required" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
</element>
<element
ref="iris:seeAlso"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element
name="limits"
type="iris:limitsType"
substitutionGroup="iris:result" />
<group
name="timeLimitsGroup">
<choice>
<element
name="perSecond"
type="nonNegativeInteger" />
<element
name="perMinute"
type="nonNegativeInteger" />
<element
name="perHour"
type="nonNegativeInteger" />
<element
name="perDay"
type="nonNegativeInteger" />
</choice>
</group>
<!-- -->
<!-- Simple Entity -->
<!-- -->
<complexType
name="simpleEntityType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="property"
minOccurs="1"
maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
name="name"
type="string"
use="required" />
<attribute
name="language"
type="language"
use="required" />
<attribute
name="uri"
type="anyURI" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<element
name="simpleEntity"
type="iris:simpleEntityType"
substitutionGroup="iris:result" />
<!-- ========================================= -->
<!-- -->
<!-- Derived Controls and Reactions -->
<!-- -->
<!-- ========================================= -->
<!-- -->
<!-- Only Check Permissions -->
<!-- -->
<element
name="onlyCheckPermissions" >
<complexType />
</element>
<!-- -->
<!-- Standard Reaction -->
<!-- -->
<element
name="standardReaction" >
<complexType>
<choice>
<element
name="controlAccepted">
<complexType/>
</element>
<element
name="controlDenied">
<complexType/>
</element>
<element
name="controlDisabled">
<complexType/>
</element>
<element
name="controlUnrecognized">
<complexType/>
</element>
</choice>
</complexType>
</element>
<!-- ========================================= -->
<!-- -->
<!-- Serialization -->
<!-- -->
<!-- ========================================= -->
<complexType
name="serializedReferralType">
<sequence>
<element name="source">
<complexType>
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
type="anyURI"
use="required" />
<attribute
name="entityClass"
type="token"
use="required" />
<attribute
name="entityName"
type="token"
use="required" />
</complexType>
</element>
<choice>
<element
ref="iris:searchContinuation" />
<element
ref="iris:entity" />
</choice>
</sequence>
</complexType>
<element
name="serialization">
<complexType>
<choice
minOccurs="1"
maxOccurs="unbounded">
<element
ref="iris:result" />
<element
name="serializedReferral"
type="iris:serializedReferralType" />
</choice>
</complexType>
</element>
</schema>
Figure 8
7. The IRIS URI
The IRIS URI has a very rigid structure. All IRIS URIs have the same
fields and look similar to users.
But the IRIS URIs are flexible because they allow different methods
to be employed to find servers and allow the use of multiple
transports (with BEEP being the default).
7.1. URI Definition
An IRIS URI [6] has the following general syntax.
iris:<registry>/<resolution>/<authority>/<class>/<name>
The full ABNF [11] follows, with certain values included from RFC
2396 [6] and RFC 2732 [15].
iris-uri = scheme ":" registry-urn "/"
[ resolution-method ] "/" authority
[ "/" entity-class "/" entity-name ]
scheme = "iris"
authority = // as specified by RFC2396
registry-urn = // as specified by IRIS
resolution-method = *(unreserved | escaped)
entity-class = *(unreserved | escaped)
entity-name = *(unreserved | escaped)
unreserved = // as specified by RFC2396
escaped = // as specified by RFC2396
An IRIS URI MUST NOT be a relative URI. The resolution method,
entity class, and entity name MUST be of the UTF-8 [12] character set
encoded with "application/x-www-form-urlencoded", as specified by
URL_ENC [14].
When the entity-class and entity-name components are not specified,
the defaults "iris" and "id" MUST be implied. For example,
"iris:dreg1//com" is interpreted as "iris:dreg1//com/iris/id".
When the resolution-method is not specified, the default is the
direct resolution method described in Section 7.3.2.
7.2. Transport Specific Schemes
The "iris" scheme name is not application transport specific. The
URI resolution process MAY determine the application transport. An
example of such a process is direct resolution (Section 7.3.2), which
uses the steps outlined in Section 7.3.3 to determine the application
transport.
A mapping between an application transport and IRIS MAY define a
scheme name signifying its use with the semantics of the IRIS URI.
The rules for determining which application transport to use are as
follows:
o If an application transport specific scheme name is present, the
application transport it signifies SHOULD be used if possible.
o If a client has a preferred transport and the resolution process
allows for its use, the client MAY use that application transport.
o Otherwise, the default application transport specified by IRIS-
BEEP [1] MUST be used.
7.3. URI Resolution
7.3.1. Registry Dependent Resolution
Interpretation and resolution of the authority component of an IRIS
URI may be altered with the specification of a resolution-method in
the URI. If no resolution-method component is specified in the URI,
the default is the direct resolution method (see Section 7.3.2).
Alternate resolution methods MAY be specified by registry types. The
identifiers for these methods MUST conform to the ABNF in Section
7.1.
7.3.2. Direct Resolution
In the direct resolution process, the authority component of an IRIS
URI may only contain a domain name, a domain name accompanied by a
port number, an IP address, or an IP address accompanied by a port
number. The authority component of the scheme indicates the server
or set of servers authoritatively responsible for a domain according
to records in DNS (Section 7.3.3) if a domain is specified. If an IP
address is specified, it indicates the specific server to be queried.
The rules for resolution are as follows:
o If the authority component is a domain name accompanied by a port
number as specified by RFC 2396, the domain name is converted to
an IP address via an A or AAAA record to the DNS.
o If the authority component is a domain name by itself, the
service/transport location (Section 7.3.3) process is used. If
this process produces no results, then the DNS is queried for the
A or AAAA RRs corresponding to the domain name, and the port
number used is the well-known port of the transport used according
to Section 7.2.
o If the authority component is an IP address, then the DNS is not
queried, and the IP address is used directly. If the port number
is present, it is used directly; otherwise, the port number used
is the well-known port of the transport used according to Section
7.2.
The use of an IPv6 address in the authority component MUST conform to
RFC 2732 [15].
7.3.3. Transport and Service Location
The direct resolution method (Section 7.3.2) uses the profiled use of
the NAPTR and SRV resource records defined in S-NAPTR [10] to
determine both the location of a set of servers for a given service
and the set of possible transports that may be used. It is
RECOMMENDED that any resolution method not making explicit use of the
direct resolution process should use S-NAPTR [10] in whatever process
it does define.
S-NAPTR [10] requires an application service label. The direct
resolution method (Section 7.3.2) uses the abbreviated form of the
registry URN as the application service label. Other resolution
methods MAY specify other application service labels.
See Appendix A for sample uses of S-NAPTR.
7.4. IRIS URI Examples
Here are some examples of IRIS URIs and their meaning:
o iris:dreg1//example.com/domain/example.com
* Finds a server authoritative for "example.com" according to the
rules of direct resolution (Section 7.3.2).
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1//example.com
* Finds a server authoritative for "example.com" according to the
rules of direct resolution (Section 7.3.2).
* The server is asked for "id" in the "iris" index, or entity
class, of the "dreg1" registry.
o iris:dreg1//com/domain/example.com
* Finds a server authoritative for "com" according to the rules
of direct-resolution (Section 7.3.2).
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1//192.0.2.1:44/domain/example.com
* Following the rules of direct-resolution (Section 7.3.2), the
server at IP address 192.0.2.1 on port 44 is queried by using
BEEP.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris.lwz:dreg1//192.0.2.1:44/domain/example.com
* Following the rules of direct-resolution (Section 7.3.2), the
server at IP address 192.0.2.1 on port 44 is queried by using a
lightweight application transport.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris.beep:dreg1//com/domain/example.com
* Finds a server authoritative for "com" according to the rules
of direct-resolution (Section 7.3.2).
* Uses the BEEP application transport.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1/bottom/example.com/domain/example.com
* Finds a server authoritative for "example.com" according to the
rules of the resolution method ’bottom’ as defined by the
registry type urn:ietf:params:xml:ns:dreg1.
* The application transport used is determined by the ’bottom’
resolution method.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris.beep:dreg1/bottom/example.com/domain/example.com
* Finds a server authoritative for "example.com" according to the
rules of the resolution method ’bottom’ as defined by the
registry type urn:ietf:params:xml:ns:dreg1.
* Uses the BEEP application transport.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
8. Checklists
8.1. Registry Definition Checklist
Specifications of registry types MUST include the following explicit
definitions:
o Formal XML syntax deriving from the IRIS XML.
o An identifying registry URN.
o Any registry specific resolution methods.
o A registration of the abbreviated registry URN as an application
service label for compliance with S-NAPTR [10]. Note that this is
a different IANA registry than the registry type URN IANA
registry.
o A list of well-known entity classes.
o A statement regarding the case sensitivity of the names in each
entity class.
8.2. Transport Mapping Checklist
Specifications of transport mappings MUST include the following
explicit definitions:
o A URI scheme name specific to the transport.
o An application protocol label for compliance with S-NAPTR [10].
See Section 7.3.3. Note that although this is a different IANA
registry than the URI scheme name IANA registry, it is RECOMMENDED
that they be the same string of characters.
o The set of allowable character set encodings for the exchange of
XML (see Section 9).
o The set of security mechanisms.
9. Internationalization Considerations
IRIS is represented in XML. XML processors are obliged to recognize
both UTF-8 and UTF-16 [12] encodings. XML provides for mechanisms to
identify and use other character encodings by means of the "encoding"
attribute in the <xml> declaration. Absence of this attribute or a
byte order mark (BOM) indicates a default of UTF-8 [13] encoding.
Thus, for compatibility reasons and per RFC 2277 [16], use of UTF-8
[13] is RECOMMENDED with IRIS.
The complete list of character set encoding identifiers is maintained
by IANA at [21].
The application-transport layer MUST define a common set of character
set encodings to be understood by both client and server.
Localization of internationalized strings may require additional
information from the client. Entity definitions SHOULD use the
"language" type defined by XML_SD [4] to aid clients in the
localization process. See Section 4.3.7.3 for an example.
10. IANA Considerations
This document uses a proposed XML namespace and schema registry
specified in XML_URN [9]. Accordingly, the following registration
information is provided for the IANA:
o URN/URI:
* urn:ietf:params:xml:ns:iris1
o Contact:
* Andrew Newton <andy@hxr.us>
* Marcos Sanz <sanz@denic.de>
o XML:
* The XML Schema specified in Section 6
11. Security Considerations
The IRIS XML layer provides no authentication or privacy facilities
of its own. It relies on the application-transport layer for all of
these abilities. Application-transports should explicitly define
their security mechanisms (see Section 8.2).
Referral IRIS registry results may contain entity lookups and search
continuations that result in a client query operation against another
registry service. Clients SHOULD NOT use authentication credentials
and mechanisms subject to replay attacks to conduct subsequent entity
lookups and search continuations.
12. References
12.1. Normative References
[1] Newton, A. and M. Sanz, "Using the Internet Registry Information
Service (IRIS) over the Blocks Extensible Exchange Protocol
(BEEP)", RFC 3983, January 2005.
[2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
xml-19980210>.
[3] World Wide Web Consortium, "Namespaces in XML", W3C XML
Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-
names-19990114>.
[4] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
xmlschema-2-20010502/>.
[5] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
xmlschema-1-20010502/>.
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[7] Moats, R., "URN Syntax", RFC 2141, May 1997.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[10] Daigle, L. and A. Newton, "Domain-based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[12] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN
0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[14] Connolly, D. and L. Masinter, "The ’text/html’ Media Type", RFC
2854, June 2000.
[15] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal
IPv6 Addresses in URL’s", RFC 2732, December 1999.
[16] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
12.2. Informative References
[17] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", RFC 3707, February 2004.
[18] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type
for the Internet Registry Information Service (IRIS)", RFC 3982,
January 2005.
[19] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September
2004.
[20] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
URIs
[21] <http://www.iana.org/assignments/character-sets>
Appendix A. S-NAPTR and IRIS Uses
A.1. Example of S-NAPTR with IRIS
This section shows an example of S-NAPTR [10] use by IRIS. In this
example, there are two registry types: REGA and REGB. There are also
two IRIS application transports: iris-a and iris-b. Given this, the