Network Working Group A. Newton
Internet-Draft VeriSign, Inc.
Expires: August 15, 2004 M. Sanz
DENIC eG
February 15, 2004
IRIS - The Internet Registry Information Service (IRIS) Core Protocol
draft-ietf-crisp-iris-core-05
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes an application layer client-server protocol
for a framework of representing the query and result operations of
the information services of Internet registries. Specified in XML,
the protocol defines generic query and result operations and a
mechanism for extending these operations for specific registry
service needs.
Newton & Sanz Expires August 15, 2004 [Page 1]
Internet-Draft iris-core February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Use of XML . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 General Concepts . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Framework Layers . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Further Reading . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Identification . . . . . . . . . . . . . . . . . . 7
3. Exchange Description . . . . . . . . . . . . . . . . . . . . 8
3.1 Request Format . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Response Format . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Extension Framework . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Derived Elements . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Registry Type Identifier Requirements . . . . . . . . . . . 12
3.3.3 Entity Classes . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.4 Names of Entities . . . . . . . . . . . . . . . . . . . . . 13
3.3.5 References to Entities . . . . . . . . . . . . . . . . . . . 14
3.3.6 Temporary Entities . . . . . . . . . . . . . . . . . . . . . 14
3.3.7 <result> Derived Elements . . . . . . . . . . . . . . . . . 15
3.3.8 <control> & <reaction> Elements . . . . . . . . . . . . . . 17
3.4 Relay Bags . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Database Serialization . . . . . . . . . . . . . . . . . . . 21
5. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 24
6. The IRIS URI . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1 URI Definition . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Transport Specific Schemes . . . . . . . . . . . . . . . . . 40
6.3 URI Resolution . . . . . . . . . . . . . . . . . . . . . . . 40
6.3.1 Registry Dependent Resolution . . . . . . . . . . . . . . . 40
6.3.2 Direct Resolution . . . . . . . . . . . . . . . . . . . . . 40
6.3.3 Transport & Service Location . . . . . . . . . . . . . . . . 41
6.4 IRIS URI Examples . . . . . . . . . . . . . . . . . . . . . 41
7. Checklists . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1 Registry Definition Checklist . . . . . . . . . . . . . . . 44
7.2 Transport Mapping Checklist . . . . . . . . . . . . . . . . 44
8. Internationalization Considerations . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
10. Security Considerations . . . . . . . . . . . . . . . . . . 47
Normative References . . . . . . . . . . . . . . . . . . . . 48
Informative References . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51
A. S-NAPTR and IRIS Uses . . . . . . . . . . . . . . . . . . . 52
A.1 An Examples of S-NAPTR with IRIS . . . . . . . . . . . . . . 52
A.2 Using S-NAPTR for Cohabitation . . . . . . . . . . . . . . . 53
B. Document Terminology . . . . . . . . . . . . . . . . . . . . 55
C. IRIS Design Philosophy . . . . . . . . . . . . . . . . . . . 56
C.1 The Basic Premise . . . . . . . . . . . . . . . . . . . . . 56
C.2 The Lure of a Universal Client . . . . . . . . . . . . . . . 57
Newton & Sanz Expires August 15, 2004 [Page 2]
Internet-Draft iris-core February 2004
C.3 Server Considerations . . . . . . . . . . . . . . . . . . . 57
C.4 Lookups, Searches, and Entity Classes . . . . . . . . . . . 58
C.5 Entities References, Search Continuations, and Scope . . . . 58
D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . 61
Newton & Sanz Expires August 15, 2004 [Page 3]
Internet-Draft iris-core February 2004
1. Introduction
The specification outlined in this document is based on the
functional requirements described in CRISP [16].
1.1 Use of XML
This document describes the specification for the Internet Registry
Information Service (IRIS), an XML text protocol with the purpose of
describing the query types and result types of various registry
information services. IRIS is specified using the Extensible Markup
Language (XML) 1.0 as described in [2], XML Schema notation as
described in [4] and [5], and XML Namespaces as described in [3].
1.2 General Concepts
Each kind of Internet registry is identified by a registry type. The
identifier for a registry type is a URI, more specifically a URN,
used within the XML instances to identify the XML schema formally
describing the set of queries, results, and entity classes allowed
within that type of registry.
The structure of these URN's makes no assumptions or restrictions on
the type of registries they identify. Therefore, IRIS may support
multiple registry types of disparate or similar nature; it is only a
matter of definition. For instance, a single registry type may be
defined for domain name registries while multiple registry types may
be defined for the various IP address registries.
A registry information server may handle queries and serve results
for multiple registry types. Each registry type that a particular
registry operator serves is a registry service instance.
IRIS and the XML schema formally describing IRIS do not specify any
registry, registry identifier, or knowledge of a particular service
instance or set of instances. IRIS is a specification for a
framework with which these registries can be defined, used, and in
some cases interoperate. The framework merely specifies the elements
for registry identification and the elements which must be used to
derive queries and results.
This framework allows a registry type to define its own structure for
naming, entities, queries, etc. through the use of XML namespaces
and XML schemas (hence, a registry type MUST be identified by the
same URI that identifies its XML namespace). In order to be
compliant, a registry type's specification must extend from this
framework.
Newton & Sanz Expires August 15, 2004 [Page 4]
Internet-Draft iris-core February 2004
The framework does define certain structures that can be common to
all registry types, such as references to entities, search
continuations, entity classes, and more. A registry type may declare
its own definitions for all of these, or it may mix its derived
definitions with the base definitions.
IRIS defines two types of referrals, an entity reference and a search
continuation. An entity reference indicates specific knowledge about
an individual entity, and a search continuation allows for
distributed searches. Both referrals may span differing registry
types and instances. No assumptions or specifications are made about
roots, bases, or meshes of entities.
1.3 Framework Layers
The IRIS framework can conceptually be thought of as having three
layers.
-----------------------------
Registry-Specific |domain | address | etc... |
-----------------------------
Common-Registry | IRIS |
-----------------------------
Application-Transport | beep | iris-lwz | etc... |
-----------------------------
The differing layers have the following responsibilities:
Registry-Specific :: Defines queries, results, and entity classes
of a specific type of registry. Each specific type of registry is
identified by a URN.
Common-Registry :: Defines base operations and semantics common to
all registry types such as search sets, result sets, referrals,
etc. It also defines the syntaxes for talking about specific
registry types.
Application-Transport :: Defines the mechanisms for
authentication, message passing, connection and session
management, etc. It also defines the URI syntax specific to the
application-transport mechanism.
1.4 Definitions
For clarity, the following definitions are supplied:
o registry type - A registry serving a specific function, such as a
Newton & Sanz Expires August 15, 2004 [Page 5]
Internet-Draft iris-core February 2004
domain registry or an address registry. Each type of registry is
assigned a URN.
o registry schema - The definition for a registry type specifying
the queries, results, and entity classes.
o authority - A reference to the server or set of server containing
information.
o resolution method - The technique used to locate an authority.
o entity class - A group of entities with a common type or common
set of characteristics.
o entity name - The identifier used to refer to a single entity
within an entity class.
o entity reference - A pointer to an entity composed of an
authority, an optional resolution method, a registry type, an
entity class, and an entity name. One type of entity reference is
the IRIS URI (defined in Section 6).
The terms "derivative", "derive", and "derivation" are used with the
same meaning for deriving one type of element from another as
specified in XML_SS [5].
1.5 Further Reading
Appendix C contains text answering the question, "Why IRIS?"
This document describes the structure at the core of IRIS. The
following documents describe the other aspects of IRIS relevant to
CRISP [16]: iris-beep [1], and iris-dreg [17].
Newton & Sanz Expires August 15, 2004 [Page 6]
Internet-Draft iris-core February 2004
2. Protocol Identification
The root element of all request XML instances MUST be <request>. The
root element of all response XML instances MUST be <response>. These
elements identify the start of the IRIS elements, the XML namespace
used as the identifier for IRIS, and the location of the schema.
These elements and the associated closing tag MUST be applied to all
requests and responses sent by both clients and servers.
An abstracted example:
<request xmlns="urn:ietf:params:xml:ns:iris1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
</request>
Figure 2
The use of the schema location URI in the <xsi:schemaLocation>
element is OPTIONAL with respect to its use by this specification,
and IRIS implementations MAY resolve it to retrieve the schema or
they MAY use a locally cached version of the schema. The presence of
this URI is mandatory according to [5]. The URI MUST be a valid URI.
Versioning of the IRIS protocol is the responsibility of the
application-transport layer but MUST be associated with the XML
namespace [3] URI representing IRIS. A change in this URI indicates
a change of the underlying schema and therefore a new version of the
protocol (and vice versa).
Newton & Sanz Expires August 15, 2004 [Page 7]
Internet-Draft iris-core February 2004
3. Exchange Description
This section describes the request and response exchanges of the
protocol. The descriptions contained within this section refer to
XML elements and attributes and their relation to the exchange of
data within the protocol. These descriptions also contain
specifications outside the scope of the formal XML syntax.
Therefore, this section will use terms defined by RFC 2119 [8] to
describe the specification outside the scope of the formal XML
syntax. While reading this section, please reference Section 5 for
needed details on the formal XML syntax.
3.1 Request Format
A <request> element contains an optional <control> element and a set
of <searchSet> elements.
The <searchSet> elements enables a client to query a particular
registry type using the URN identifying the registry type. This can
be found in one of its two children: <lookupEntity> and <query>.
The <lookupEntity> element describes the lookup of an entity in a
specific registry. This element has three attributes:
'registryType', 'entityClass', and 'entityName'. The 'registryType'
attribute contains the registry identifier for the registry type in
which the lookup operation is to take place. The 'entityClass'
attribute contains the token identifying the index for which the
lookup operation is to take place, and the 'entityName' attribute
contains the name of the entity to lookup.
The <query> element is abstract and may not legally appear in an XML
instance. It provides the base type to be used by registry schemas
to define derived query types. This derivation mechanism is
described in Section 3.3.
Each <searchSet> may also contain a <bag> element. When this element
appears as a child of <searchSet>, it MUST NOT contain the 'id'
attribute. For a description of the <bag> element, see Section 3.4.
The <control> element may contain one child element of any XML
namespace. This child element allows a client to signal to a server
the desire for special states or processing. An example of one such
<control> child element may be found in Section 3.3.8.
3.2 Response Format
The <response> element contains an optional <reaction> element, a set
of <resultSet> elements, and an optional <bags> element.
Newton & Sanz Expires August 15, 2004 [Page 8]
Internet-Draft iris-core February 2004
The <resultSet> elements are responses to a <searchSet> request. The
contents of this element contain an <answer> element, an optional
<additional> element, and error elements if applicable.
The children of the <answer> element are of the following types:
o <result> is an abstract element and may not be legally placed in
an XML instance. It provides the base type to be used by registry
schemas to define derived result types. This derivation mechanism
is described in Section 3.3.
o <entity> is an element specifying an entity reference. It has the
following attributes to refer to the entity: 'authority',
'resolution' (optional), 'registryType', 'entityClass',
'entityName', and 'temporaryReference' (optional, see Section
3.3.6). It also may have a <displayName> child element. This
child element specifies a human-friendly name (and appropriate
language via its 'language' attribute) so the clients may present
this entity reference to a user in a friendlier fashion. The
<entity> element may also have a 'bagRef' attribute. If present,
this attribute must contain an XML identifier to a <bag> element
in the <bags> section of the result set. For a description of the
'bagRef' attribute, see Section 3.4.
o The <searchContinuation> element children contains an <authority>
element, an optional <resolution> element and a <query> element.
The <authority> and <resolution> elements indicate where the
search continuation should be directed, and the <query> element is
the query to be conducted. The <searchContinuation> element may
also contain a 'bagRef' attribute, and has the same meaning and
purpose as specified with the <entity> element. For a description
of the 'bagRef' attribute, see Section 3.4.
When following entity references and search continuations, clients
SHOULD only follow an <entity> or <searchContinuation> response once.
Failure to do so may result in the client process getting stuck in a
never-ending query loop commonly known as a referral loop.
The <additional> element only contains <result> elements, as
described above. This element is provided to allow a server to
indicate to a client results that were not specifically queried but
are related to the queried results, thus allowing the client the
ability to properly display this distinction to a user. The
<additional> element use is optional.
The following elements, representing error conditions, may be
returned:
Newton & Sanz Expires August 15, 2004 [Page 9]
Internet-Draft iris-core February 2004
o <insufficientResources> - the corresponding query requires
resources unobtainable by the server.
o <invalidName> - a name given in a query is not syntactically
correct.
o <invalidSearch> - parameters of the corresponding query are not
semantically meaningful.
o <queryNotSupported> - the corresponding query is not supported by
this server.
o <limitExceeded> - the corresponding query requires more resources
than allowed.
o <nameNotFound> - the name given in a query does not match a known
entity.
o <permissionDenied> - the authentication given does not allow
access to a specific result entry.
o <bagUnrecognized> - the contents of a bag were unrecognized. See
Section 3.4.
o <bagUnacceptable> - the contents of a bag were not and never will
be acceptable. See Section 3.4.
o <bagRefused> - the contents of a bag were not acceptable at this
time. See Section 3.4.
o A derivative of <genericCode>, as described in Section 3.3.
The <resultSet> section is divided up into the <answer> and
<additional> sections in order to allow easier processing and
navigation of the results by a client. Servers MUST return the
direct answers to queries in the <answer> element, and MAY return
results in the <additional> element for which a reference has been
made to in the <answer> element. Results in the <additional> element
MUST have been referenced in the <answer> either as direct children
of the <answer> element or as a deeper descendant of the <answer>
element.
This serves two purposes. First, it may eliminate a requery by the
client for references contained in the <answer> element. Second, it
distinguishes between results that are a direct result of a query and
those that would have been returned had the client followed the
appropriate referrals, thus giving clients a hint as to how to
process or display the returned results. For instance, clients
Newton & Sanz Expires August 15, 2004 [Page 10]
Internet-Draft iris-core February 2004
constructing complex displays using tree navigation widgets will know
that results in the <answer> element should all be directly beneath
the root node of the tree, while results in the <additional> element
are to be leaf nodes of those produced from the <answer> element.
A <reaction> element (child of <response>) is a response to a
<control> element, and provide a means for a server to advise a
client of the affect of a <control> element.
The <bags> element (child of <response>) is optional. It contains
<bag> elements, and the contents of each <bag> element is one element
in any XML namespace. Each <bag> element has an 'id' attribute,
which is referenced by the 'bagRef' attribute of entity references
(<entity>) and search continuations (<searchContinuation>). See
Section 3.4.
3.3 Extension Framework
Because the IRIS schema defines only one query type, no registry
structure, and only two stand-alone result types, it is of limited
use by itself. Extension of IRIS is accomplished through the use a
base IRIS schema, as defined in XML_SD [4] and XML_SS [5], and
extension of it by schemas constructed on top of IRIS.
3.3.1 Derived Elements
The XML Schema definition of IRIS requires schemas of registry types
to derive element types from base types in the IRIS definition. The
registry schemas MUST derive elements for definition of typed queries
and results.
While the IRIS schema definition does not prohibit the derivation of
any elements, registry schemas SHOULD restrict the derivations to the
following types:
o <query> - as defined this element contains no content and has no
valid attributes. It is abstract and therefore only derivatives
of it appear in XML instances. Registry schemas derive from this
element to define the queries allowed.
o <result> - as defined this element contains no content and has
five valid attributes: 'authority', 'resolution' (optional),
'registryType', 'entityClass' 'entityName', and
'temporaryReference' (optional, see Section 3.3.6). It is
abstract and therefore only derivatives of it appear in XML
instances. Registry schemas derive from this element to define
results that may be returned from a query.
Newton & Sanz Expires August 15, 2004 [Page 11]
Internet-Draft iris-core February 2004
o <genericCode> - as defined, this element is an instance of
<codeType>. It contains the optional elements <explanation> and
<language> to further describe the nature of the error.
o <entity> - identifies a reference to an entity. Registry schemas
SHOULD use its type ('entityType'), but MAY use it directly. The
advantage of using the type vs. referencing the element directly
is the chance to define the name of the element and to use that
name descriptively, for instance, as the role which the entity
plays with respect to another entity.
o <seeAlso> - contains one or more <entity> elements. This element
indicates one or more references to entities that have indirect
association with a parent element representing an entity.
Registry schemas MAY derive from this element or MAY use it
directly.
3.3.2 Registry Type Identifier Requirements
The identifier for a registry type and the XML namespace identifier
used by the XML Schema describing the registry MUST be the same.
These identifiers MUST be restricted to any valid URN [7] in
compliance with XML_URN [9].
This is a restriction on XML_NS [3], which specifies an XML namespace
identifier is any valid URI [6].
Because these URN's represent namespace identifiers which are to be
used in XML documents for the purposes of XML namespaces as specified
by XML_NS [3], they MUST be of the class "ns" as defined in XML_URN
[9]. Registry URN's conforming to XML_URN [9] are case insensitive.
Registry URN's MAY be abbreviated to the part following the class
component and its separator of the URN. For example, the full URN
"urn:ietf:params:xml:ns:dreg1" may be abbreviated to "dreg1".
This abbreviation MUST NOT be used inside of XML instances in use
with IRIS where XML Schema [4] specifies the use of a URI for schema
identification or where XML_NS [3] specifies the use of a URI for XML
namespace identification.
3.3.3 Entity Classes
Entity classes are provided in IRIS to help avoid collisions with
entity names within any given registry type. Their specification in
queries also allows server implementations to quickly narrow search
or lookup scopes to a single index.
Newton & Sanz Expires August 15, 2004 [Page 12]
Internet-Draft iris-core February 2004
For instance, the entity name "10.0.1.0" would refer to separate
entities in the "name-server" and "network" classes. The entity
"10.0.1.0" in the "name-server" class may refer to the name server
host that is also multi-homed by address 192.178.0.1 and known in DNS
as "ns.example.com", whereas the entity "10.0.1.0" in the "network"
class may refer to the network 10.0.1/24.
IRIS defines two default entity classes of "local" and "iris" which
MAY NOT be redefined. These entity classes MUST be valid in all
registry types.
The "local" class is reserved for entities defined locally by a
server operator and does not denote any particular type of entity. A
lookup in this entity class MAY result in an entity reference or
search continuation. For example, "iris:dreg1//example.com/local/
myhosts" may result in a search continuation yielding the nameservers
for example.com.
The "iris" class is reserved for entities specific to a particular
service instance. It MUST contain the following entity names (see
Section 3.3.4:
o "id" which yields a result of <serviceIdentification> (see Section
3.3.7.1).
o "limits" which yields a result of <limits> (see Section 3.3.7.2 ).
This entity class MAY contain other locally defined entities as well.
The names of entity classes in a registry schema are of type token
defined by XML_SD [4]. Their case sensitivity MUST be defined by the
definition of the registry type. In general, they SHOULD be case
insensitive.
3.3.4 Names of Entities
The names of entities in a registry schema are of type token defined
by XML_SD [4].
Names of entities SHOULD be unique within an instance of any
particular entity class within a registry. Two entities SHOULD NOT
have the same name, but a single entity MAY be known by multiple
names. In situations where a single name may result in two entities,
the registry schema SHOULD make allowances by defining result types
that contain entity references to both entities (i.e. "example.com"
can refer to both the domain example.com and the host example.com).
However, this type of conflict SHOULD generally be avoided by the
proper use of entity classes.
Newton & Sanz Expires August 15, 2004 [Page 13]
Internet-Draft iris-core February 2004
The case sensitivity of entity names is dependent on the entity class
in which they reside. The definition of a registry type MUST specify
the case sensitivity for entity names. A registry type MAY define
the entity names of differing entity classes to have different case
sensitivity.
3.3.5 References to Entities
The element <entity> allows references to entities in result sets,
either as a direct child of <resultSet> or within a more complex
structure that derives from <result>. The <entity> element is
defined by 'entityType'. Registry schemas SHOULD define elements of
this type when referencing entities but may use the <entity> element
directly. Defining a new element of the 'entityType' type allows a
registry schema to use the name of the new element as a role
signifying the relationship the referenced entity has with the
referrer. An element of type 'entityType' other than <entity> MUST
NOT be used as a substitute when the <entity> element is declared
(such as in the <answer> section of the <resultSet>).
The <entity> element (and elements of type 'entityType') can have a
child element of <displayName> with an optional 'language' attribute.
These are provided so that servers may provide to clients a more
human friendly meaning to the entity reference. This is often useful
to users navigating referral structures.
3.3.6 Temporary Entities
There may exist instances where an entity reference needs to be
temporary. As an example, a particular type of result may only have
one unique key. If that key contained semantic meaning that may not
be exposed to all users, a synthetic key will need to be substituted.
As an additional example, there may be times when data in the data
store is not normalized in the same manner as that expressed by the
registry schema. In the registry schema, objects of type A may
reference objects of type B. But in the data store, objects of type
A may contain objects of type B. Again, a synthetic key will need to
be temporarily produced.
Results and entity references can be declared temporary by using the
'temporaryReference' attribute. This attribute is of type boolean
[4] and has a default value of "false". It is optional for <result>
derivatives and elements of type 'entityType'.
When this attribute is used, the entity reference data (i.e.
'entityClass', 'entityName', etc...) is considered to have only
response scope and MAY NOT be valid for use in subsequent requests
Newton & Sanz Expires August 15, 2004 [Page 14]
Internet-Draft iris-core February 2004
nor consistent with subsequent responses. Clients MUST NOT use a
temporary entity reference in any request. A server MUST include the
referent of any temporary entity reference in the <additional>
section of the same <resultSet>
3.3.7 <result> Derived Elements
The base IRIS framework does contain three elements directly derived
from the <result> element for use by any registry type.
3.3.7.1 <serviceIdentification>
An example of an <serviceIdentification> result:
<serviceIdentification
authority="example.com" registryType="dreg1"
entityClass="iris"
entityName="id" >
<authorities>
<authority> example.com </authority>
<authority> example.net </authority>
<authority> example.org </authority>
</authorities>
<operatorName>
Ineternet Assigned Numbers Authority
</operatorName>
<eMail>
iana@iana.org
</eMail>
</serviceIdentification>
The <serviceIdentification> element is provided to allow IRIS clients
the ability to reference IRIS service instances. It contains the
following elements:
o <authorities> - This element contains one or more <authority>
elements. Each <authority> element contains a URI authority
component for which the server has results. While a server MAY
only return a partial list of its authority areas depending on
operator policy, it MUST return the authority for which the client
has requested.
o <operatorName> - This element contains the name of the operator of
the server.
o <eMail> - These optional elements contain email addresses of the
operator of the service instance.
Newton & Sanz Expires August 15, 2004 [Page 15]
Internet-Draft iris-core February 2004
o <phone> - These optional elements contain phone numbers of the
operator of the service instance.
o <seeAlso> - See Section 3.3.1 for its definition.
3.3.7.2 <limits>
An example of a <limits> result:
<limits
authority="example.com" registryType="dreg1"
entityClass="iris" entityName="limits">
<totalQueries>
<perHour>2</perHour>
<perDay>15</perDay>
</totalQueries>
<totalResults>
<perHour>25</perHour>
<perDay>200</perDay>
</totalResults>
<totalSessions>
<perHour>2</perHour>
<perDay>15</perDay>
</totalSessions>
</limits>
The <limits> element provides a mechanism to allow a server to inform
a client of the limits it may encounter from over use of the service.
The contents describe the service limitations to a client at the
current level of access. The contents of this element are as
follows:
o <totalQueries> - This element describes the total number of
queries that the server will accept. The children of this element
indicate this number per a unit of time. The children are
<perSecond>, <perMinute>, <perHour>, and <perDay>. Each child
MUST only appear once as a child of <totalQueries>, but more than
one child MAY be present. For example, a server could indicate
that it will accept 15 queries a minute but only 60 queries a day.
o <totalResults> - This element describes the total number of
results that the server will send to a client. The children of
this element indicate this number per unit of time in the same
manner as <totalQueries>.
o <totalSessions> - This element describes the total number of
sessions that the server will accept from a client. The children
Newton & Sanz Expires August 15, 2004 [Page 16]
Internet-Draft iris-core February 2004
of this element indicate this number per unit of time in the same
manner as <totalQueries>. The definition of a session is defined
the by application transport layer.
3.3.7.3 <simpleEntity>
An example of a <simpleEntity> result:
<simpleEntity
authority="example.com" registryType="dreg1"
entityClass="local"
entityName="notice" >
<property name="legal" language="en">
Example.com is reserved according to RFC 2606.
</property>
</simpleEntity>
The <simpleEntity> element is provided so that service operators may
make simple additions to other entities without the need for deriving
entirely new registry types. Its definition allows service operators
to reference it from other entities (using, for instance, a <seeAlso>
element). The <simpleEntity> is meant to represent name and value
pairs of strings, allowing each pair to be associated with a specific
language qualifier, and optional URI pointing to more information.
Clients may easily display such information as a two-column table.
Uses needing binary data or richer data structures are out of scope
for this element. When such usage scenarios arise, it is likely that
a client will need specific knowledge for handling such data thus
calling into question the need for a new registry type.
3.3.8 <control> & <reaction> Elements
When a client sends an <onlyCheckPermissions> control, it is asking
the server to only check to see if adequate permissions are available
to execute the queries in the associated request. A server MUST
respond to this control with a <standardReaction> element.
The <standardReaction> element provides a server with a standard
means to respond to controls. It contains three children:
o <controlAccepted> - the processing or state needed by the control
has been accepted.
o <controlDenied> - the processing or state needed by the control
has been denied (a transient failure).
Newton & Sanz Expires August 15, 2004 [Page 17]
Internet-Draft iris-core February 2004
o <controlDisabled> - the processing or state needed by the control
cannot be activated (a permanent failure).
o <controlUnrecognized> - the control is not recognized (a permanent
failure).
An example of an IRIS XML exchange using these elements:
C: <?xml version="1.0"?>
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C:
C: <control>
C: <onlyCheckPermissions />
C: </control>
C:
C: <searchSet>
C:
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C:
C: </searchSet>
C:
C: </request>
S: <?xml version="1.0"?>
S: <response xmlns="urn:ietf:params:xml:ns:iris1"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
S:
S: <reaction>
S: <standardReaction>
S: <controlAccepted />
S: </standardReaction>
S: </reaction>
S:
S: <resultSet>
S: <answer>
S:
S: <simpleEntity
S: authority="example.com" registryType="dreg1"
S: entityClass="local" entityName="AUP" >
S: <property name="legal" language="en">
S: It is illegal to use information from this service
S: for the purposes of sending unsolicited bulk email.
S: </property>
S: </simpleEntity>
Newton & Sanz Expires August 15, 2004 [Page 18]
Internet-Draft iris-core February 2004
S:
S: </answer>
S: </resultSet>
S:
S: </response>
3.4 Relay Bags
IRIS employs the use of bags to allow a server to relay information
to a referent server via the client. The contents of the bags are
not defined by IRIS, and the client MUST NOT make any assumptions
about the contents of a bag when relaying it from one server to
another.
When a server returns a result set to a client, the <response>
element may contain a <bags> child element. This child element
contains one or more <bag> elements. Each of these MUST contain an
'id' attribute containing the XML datatype ID. Entity references and
search continuations that need to specify a bag to be used when they
are followed MUST have a 'bagRef' attribute containing the XML
datatype IDREF. See Section 3.2. This allows the response to only
specify a bag once but allows each entity reference or search
continuation (in all result sets) to have a distinct bag as needed.
When following an entity reference or search continuation that
specifies the use of a bag, the client MUST include the referenced
bag in the search set as a child of the <searchSet> element. See
Section 3.1.
See Section 3.2 for the list of errors a server may return to a
client when a bag is received. A server MUST NOT ignore a bag when
it is received. A server MUST NOT ignore a received bag element and
one of the errors from Section 3.2 MUST be returned.
An example of an IRIS XML exchange using these elements:
C: <?xml version="1.0"?>
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C:
C: <searchSet>
C:
C: <bag>
C: <simpleBag xmlns="http://example.com/">
C: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
C: </simpleBag>
C: </bag>
Newton & Sanz Expires August 15, 2004 [Page 19]
Internet-Draft iris-core February 2004
C:
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C:
C: </searchSet>
C:
C: </request>
S: <?xml version="1.0"?>
S: <response xmlns="urn:ietf:params:xml:ns:iris1"
S: xmlns:iris="urn:ietf:params:xml:ns:iris1"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
S:
S: <resultSet>
S: <answer>
S:
S: <entity authority="example.com" bagRef="x1"
S: registryType="dreg1"
S: entityClass="local" entityName="AUP"
S: iris:referentType="ANY" >
S: <displayName language="en">
S: Acceptable Usage Policy
S: </displayName>
S: </entity>
S:
S: </answer>
S: </resultSet>
S:
S: <bags>
S:
S: <bag id="x1">
S: <simpleBag xmlns="http://example.com/">
S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ
S: </simpleBag>
S: </bag>
S:
S: </bags>
S: </response>
Newton & Sanz Expires August 15, 2004 [Page 20]
Internet-Draft iris-core February 2004
4. Database Serialization
This section describes a method for serializing IRIS registry
entities. The descriptions contained within this section refer to
XML elements and attributes and their relation to this serialization
process. These descriptions also contain specifications outside the
scope of the formal XML syntax. Therefore, this section will use
terms defined by RFC 2119 [8] to describe the specification outside
the scope of the formal XML syntax. While reading this section,
please reference Section 5 for needed details on the formal XML
syntax.
A database of IRIS entities can be serialized to file storage with
XML [2] using the IRIS defined <serialization> element. This element
contains <result> element derivatives, and <serializedReferral>
elements.
Derivatives of the <result> element are entities. Servers loading
these entities MUST place the entity in the entity class specified by
the elements 'registryType', 'entityClass', and 'entityName'
attributes and any entity class which the entity may apply according
to explicitly defined children of that element. For instance, if a
registry type has two entity classes of "foo" and "bar" and a
<result> derivative has the attributes entityClass="foo" and
entityName="one" and a child element <bar>two</bar>, the server is to
enter that entity into the entity class "foo" as the name "one" and
into the entity class "bar" as the name "two".
Servers loading entities as serialized derivatives of the <result>
element MAY translate the authority attribute. Servers will likely
need to do this if the authority for the entity has changed.
<searchContinuation> elements allow the serialization of static
referrals. When this element appears as a child of the
<serialization> element, it MUST have the 'authority',
'registryType', 'entityClass', and 'entityName' attributes.
<serializedReferral> elements allow the serialization of explicit
entity references and search continuations. This element has a child
<source> element, containing the 'authority', 'resolution'
(optional), 'registryType', 'entityClass', and 'entityName'
attributes. The attributes of this element are to be used to signify
the entity which can be referenced to yield this referral.
As mentioned above, there may be times when a server needs to
translate the authority attribute of a loaded entity.
Implementations must also beware of this need for referrals. During
deserialization, servers MUST change the authority attribute of a
Newton & Sanz Expires August 15, 2004 [Page 21]
Internet-Draft iris-core February 2004
referral (either <entity> or an element of type 'entityType' or
<source> child of <serializedReferral>) to contain a valid authority
of the server if the serialized attribute is empty. During
serialization, servers and their related processes MUST leave the
authority attribute empty for referral in which the referent is an
entity for which the server answers queries.
The following is an example of serialized IRIS.
<iris:serialization
xmlns:iris="urn:ietf:params:xml:ns:iris1"
xmlns="urn:ietf:params:xml:ns:iris1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<serviceIdentification
authority="iana.org" registryType="dreg1"
entityClass="iris"
entityName="id" >
<authorities>
<authority> iana.org </authority>
</authorities>
<operatorName>
Internet Assigned Numbers Authority
</operatorName>
<eMail>
dbarton@iana.org
</eMail>
<seeAlso
iris:referentType="iris:simpleEntity"
authority="iana.org" registryType="dreg1"
entityClass="local"
entityName="notice">
<displayName language="en">
Legal Notice
</displayName>
</seeAlso>
</serviceIdentification>
<serializedReferral>
<source
authority="example.com" registryType="dreg1"
entityClass="iris"
entityName="id"/>
<entity
iris:referentType="iris:serviceIdentification"
authority="iana.org" registryType="dreg1"
entityClass="iris" entityName="id"/>
Newton & Sanz Expires August 15, 2004 [Page 22]
Internet-Draft iris-core February 2004
</serializedReferral>
<simpleEntity
authority="iana.org" registryType="dreg1"
entityClass="local"
entityName="notice" >
<property name="legal" language="en">
Please use the net wisely!
</property>
</simpleEntity>
</iris:serialization>
Newton & Sanz Expires August 15, 2004 [Page 23]
Internet-Draft iris-core February 2004
5. Formal XML Syntax
IRIS is specified in XML Schema notation. The formal syntax
presented here is a complete schema representation of IRIS suitable
for automated validation of IRIS XML instances.
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:iris="urn:ietf:params:xml:ns:iris1"
targetNamespace="urn:ietf:params:xml:ns:iris1"
elementFormDefault="qualified" >
<annotation>
<documentation>
Internet Registry Information Service (IRIS) Schema v1
</documentation>
</annotation>
<!-- ========================================= -->
<!-- -->
<!-- The Transactions -->
<!-- -->
<!-- ========================================= -->
<element name="request">
<complexType>
<sequence>
<element
name="control"
type="iris:controlType"
minOccurs="0"
maxOccurs="1" />
<element
name="searchSet"
type="iris:searchSetType"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element name="response">
<complexType>
<sequence>
<element
name="reaction"
type="iris:reactionType"
Newton & Sanz Expires August 15, 2004 [Page 24]
Internet-Draft iris-core February 2004
minOccurs="0"
maxOccurs="1" />
<element
name="resultSet"
type="iris:resultSetType"
minOccurs="1"
maxOccurs="unbounded" />
<element
name="bags"
type="iris:bagsType"
minOccurs="0"
maxOccurs="1" />
</sequence>
</complexType>
</element>
<!-- ========================================= -->
<!-- -->
<!-- Search Sets and Result Sets -->
<!-- -->
<!-- ========================================= -->
<complexType
name="searchSetType" >
<sequence>
<element
name="bag"
type="iris:bagType"
minOccurs="0"
maxOccurs="1" />
<choice>
<element
name="lookupEntity"
type="iris:lookupEntityType" />
<element
ref="iris:query" />
</choice>
</sequence>
</complexType>
<complexType
name="resultSetType" >
<sequence>
<element
name="answer"
minOccurs="1"
maxOccurs="1">
<complexType>
Newton & Sanz Expires August 15, 2004 [Page 25]
Internet-Draft iris-core February 2004
<sequence>
<element
ref="iris:result"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:entity"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:searchContinuation"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element
name="additional"
minOccurs="0"
maxOccurs="1">
<complexType>
<sequence>
<element
ref="iris:result"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<choice
minOccurs="0"
maxOccurs="1" >
<element
name="insufficientResources"
type="iris:codeType" />
<element
name="invalidName"
type="iris:codeType" />
<element
name="invalidSearch"
type="iris:codeType" />
<element
name="queryNotSupported"
type="iris:codeType" />
<element
name="limitExceeded"
type="iris:codeType" />
<element
Newton & Sanz Expires August 15, 2004 [Page 26]
Internet-Draft iris-core February 2004
name="nameNotFound"
type="iris:codeType" />
<element
name="permissionDenied"
type="iris:codeType" />
<element
name="bagUnrecognized"
type="iris:codeType" />
<element
name="bagUnacceptable"
type="iris:codeType" />
<element
name="bagRefused"
type="iris:codeType" />
<element
ref="iris:genericCode"/>
</choice>
</sequence>
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Controls and Reactions -->
<!-- -->
<!-- ========================================= -->
<complexType
name="controlType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
<complexType
name="reactionType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
Newton & Sanz Expires August 15, 2004 [Page 27]
Internet-Draft iris-core February 2004
<!-- ========================================= -->
<!-- -->
<!-- Queries and Lookups -->
<!-- -->
<!-- ========================================= -->
<complexType
name="queryType" />
<element
name="query"
type="iris:queryType"
abstract="true" />
<complexType
name="lookupEntityType" >
<attribute
name="registryType"
type="anyURI"
use="required" />
<attribute
name="entityClass"
type="token"
use="required" />
<attribute
name="entityName"
type="token"
use="required" />
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Results -->
<!-- -->
<!-- ========================================= -->
<complexType
name="resultType">
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
use="required"
Newton & Sanz Expires August 15, 2004 [Page 28]
Internet-Draft iris-core February 2004
type="anyURI" />
<attribute
name="entityClass"
use="required"
type="token" />
<attribute
name="entityName"
use="required"
type="token" />
<attribute
name="temporaryReference"
default="false"
type="boolean" />
</complexType>
<element
name="result"
type="iris:resultType"
abstract="true" />
<!-- ========================================= -->
<!-- -->
<!-- Errors -->
<!-- -->
<!-- ========================================= -->
<complexType
name="codeType">
<sequence
minOccurs="0"
maxOccurs="unbounded">
<element
name="explanation">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
use="required"
name="language"
type="language" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
Newton & Sanz Expires August 15, 2004 [Page 29]
Internet-Draft iris-core February 2004
<element
name="genericCode"
type="iris:codeType"
abstract="true" />
<!-- ========================================= -->
<!-- -->
<!-- Entity References and -->
<!-- Search Continuations -->
<!-- -->
<!-- ========================================= -->
<complexType
name="entityType">
<sequence>
<element
name="displayName"
minOccurs="0"
maxOccurs="1">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
name="language"
use="required"
type="language" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
use="required"
type="anyURI" />
<attribute
name="entityClass"
use="required"
type="token" />
<attribute
Newton & Sanz Expires August 15, 2004 [Page 30]
Internet-Draft iris-core February 2004
name="entityName"
use="required"
type="token" />
<attribute
name="referentType"
use="required"
form="qualified"
type="iris:referentTypeType" />
<attribute
name="temporaryReference"
default="false"
type="boolean" />
<attribute
name="bagRef"
type="IDREF" />
</complexType>
<element
name="entity"
type="iris:entityType" />
<simpleType
name="referentTypeType">
<union
memberTypes="QName iris:anyLiteralType" />
</simpleType>
<simpleType
name="anyLiteralType">
<restriction
base="string">
<enumeration
value="ANY" />
</restriction>
</simpleType>
<complexType
name="searchContinuationType">
<sequence>
<element
name="authority"
type="token"
minOccurs="1"
maxOccurs="1" />
<element
name="resolution"
type="token"
minOccurs="0"
Newton & Sanz Expires August 15, 2004 [Page 31]
Internet-Draft iris-core February 2004
maxOccurs="1" />
<element ref="iris:query" />
</sequence>
<attribute
name="bagRef"
type="IDREF" />
</complexType>
<element
name="searchContinuation"
type="iris:searchContinuationType" />
<!-- ========================================= -->
<!-- -->
<!-- Bags -->
<!-- -->
<!-- ========================================= -->
<complexType
name="bagsType">
<sequence>
<element
name="bag"
minOccurs="1"
maxOccurs="unbounded">
<complexType>
<complexContent>
<extension
base="iris:bagType">
<attribute
use="required"
name="id"
type="ID" />
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</complexType>
<complexType
name="bagType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
Newton & Sanz Expires August 15, 2004 [Page 32]
Internet-Draft iris-core February 2004
</sequence>
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Derived Results for use with all -->
<!-- registry types. -->
<!-- -->
<!-- ========================================= -->
<!-- -->
<!-- See Also -->
<!-- -->
<element
name="seeAlso"
type="iris:entityType" />
<!-- -->
<!-- Service Identification -->
<!-- -->
<complexType
name="serviceIdentificationType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="authorities"
minOccurs="1"
maxOccurs="1">
<complexType>
<sequence>
<element
name="authority"
type="token"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element
name="operatorName"
type="string"
minOccurs="0"
maxOccurs="1" />
<element
Newton & Sanz Expires August 15, 2004 [Page 33]
Internet-Draft iris-core February 2004
name="eMail"
type="string"
minOccurs="0"
maxOccurs="unbounded" />
<element
name="phone"
type="string"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:seeAlso"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element
name="serviceIdentification"
type="iris:serviceIdentificationType"
substitutionGroup="iris:result" />
<!-- -->
<!-- Limits -->
<!-- -->
<complexType
name="limitsType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="totalQueries"
minOccurs="0"
maxOccurs="1" >
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
</element>
<element
name="totalResults"
minOccurs="0"
maxOccurs="1" >
Newton & Sanz Expires August 15, 2004 [Page 34]
Internet-Draft iris-core February 2004
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
</element>
<element
name="totalSessions"
minOccurs="0"
maxOccurs="1" >
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
</element>
</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 -->
Newton & Sanz Expires August 15, 2004 [Page 35]
Internet-Draft iris-core February 2004
<!-- -->
<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 -->
<!-- -->
<!-- ========================================= -->
<!-- -->
Newton & Sanz Expires August 15, 2004 [Page 36]
Internet-Draft iris-core February 2004
<!-- 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
Newton & Sanz Expires August 15, 2004 [Page 37]
Internet-Draft iris-core February 2004
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 9
Newton & Sanz Expires August 15, 2004 [Page 38]
Internet-Draft iris-core February 2004
6. The IRIS URI
The IRIS URI has a very rigid structure but is flexible in how it may
be used. Its structure is rigid in that all IRIS URI's have the same
fields and all look similar to users.
They are flexible because they allow different methods to be employed
to find servers and they allow the use of multiple transports (with
BEEP being the default).
6.1 URI Definition
An IRIS URI [6] has the following general syntax.
iris:<registry>/<resolution>/<authority>/<class>/<name>
The full ABNF [11] with certain values included from RFC 2396 [6] and
RFC 2732 [14] follows.
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 [13].
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 to be interpreted "iris:dreg1//com/iris/id".
When the resolution-method is not specified, the default is the
direct resolution method described in Section 6.3.2.
Despite the fact that URI's are not friendly to all humans, care
should be taken in the definition of names of entity classes to make
them readable and transcribable. One aspect of this is the use of
dashes to separate meaningful words over the use of other styles such
Newton & Sanz Expires August 15, 2004 [Page 39]
Internet-Draft iris-core February 2004
as camel back notation (e.g. "service-definition" instead of
"serviceDefinition").
6.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 the direct resolution (Section 6.3.2)
process, which uses the steps outlined in Section 6.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:
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 as specified by
IRIS-BEEP [1] MUST be used.
6.3 URI Resolution
6.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 6.3.2).
Alternate resolution methods MAY be specified by registry types. The
identifiers for these methods MUST conform to the ABNF in Section
6.1.
6.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 6.3.3) if a domain is specified or
indicates the specific server to be queried if an IP address is
Newton & Sanz Expires August 15, 2004 [Page 40]
Internet-Draft iris-core February 2004
specified.
The rules for resolution are:
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 6.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 6.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
6.2.
The use of an IPv6 address in the authority component MUST conform to
RFC 2732 [14].
6.3.3 Transport & Service Location
The direct resolution method (Section 6.3.2) uses the profiled use of
the NAPTR and SRV resource records as 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. Any resolution
method not deferring to the direct resolution process SHOULD use
S-NAPTR [10] for this purpose.
S-NAPTR [10] requires an application service label. The direct
resolution method (Section 6.3.2) uses the abbreviated form the
registry URN as the application service label. Other resolution
methods MAY specify other application service labels.
See Appendix A for example uses of S-NAPTR.
6.4 IRIS URI Examples
Here are some examples of IRIS URI's 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 6.3.2).
Newton & Sanz Expires August 15, 2004 [Page 41]
Internet-Draft iris-core February 2004
* 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 6.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 6.3.2).
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1//10.0.1.1:44/domain/example.com
* Following the rules of direct-resolution (Section 6.3.2), the
server at IP address 10.0.1.1 on port 44 is queried using BEEP.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris-lwz:dreg1//10.0.1.1:44/domain/example.com
* Following the rules of direct-resolution (Section 6.3.2), the
server at IP address 10.0.1.1 on port 44 is queried 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 6.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
Newton & Sanz Expires August 15, 2004 [Page 42]
Internet-Draft iris-core February 2004
* Finds a server authoritative for "example.com" according to the
rules of the resolution method 'bottom' 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' 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.
Newton & Sanz Expires August 15, 2004 [Page 43]
Internet-Draft iris-core February 2004
7. Checklists
7.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, 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.
7.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 6.3.3. Note, this is a different IANA registry than
the scheme name IANA registry, however, there is nothing stopping
them from being the same string of characters.
o The set of allowable character set encodings for the exchange of
XML (see xref target="internationalization"/>).
Newton & Sanz Expires August 15, 2004 [Page 44]
Internet-Draft iris-core February 2004
8. 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) means a default of UTF-8 encoding. Thus, for
compatibility reasons, and per RFC 2277 [15], use of UTF-8 is
RECOMMENDED with IRIS.
The complete list of character set encoding identifiers is maintained
by IANA at [19].
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 by the client. Entity definitions SHOULD use the
"language" type defined by XML_SD [4] to aid clients in the
localization process. See Section 3.3.7.3 as an example.
Newton & Sanz Expires August 15, 2004 [Page 45]
Internet-Draft iris-core February 2004
9. IANA Considerations
This document makes use of 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 5
Newton & Sanz Expires August 15, 2004 [Page 46]
Internet-Draft iris-core February 2004
10. Security Considerations
IRIS provides no authentication or privacy facilities of its own. It
relies on the application-transport layer for all of these abilities.
Implementers need to fully understand the application-transports
employed by IRIS.
Referral IRIS registry results may contain entity lookups and search
continuations which result in a client query operation against
another registry service. The authentication credentials and
mechanisms subject to replay attacks SHOULD NOT be used to conduct a
subsequent entity lookup or search continuation.
Newton & Sanz Expires August 15, 2004 [Page 47]
Internet-Draft iris-core February 2004
Normative References
[1] Newton, A. and M. Sanz, "Using the Internet Registry
Information Service (IRIS) over the Blocks Extensible Exchange
Protocol (BEEP)", draft-ietf-crisp-iris-beep-05 (work in
progress), January 2004.
[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", RFC 2119, BCP 14, March 1997.
[9] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
January 2004.
[10] Daigle, L. and A. Newton, "Domain-based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", draft-daigle-napstr-03 (work in progress),
November 2002.
[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] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
Newton & Sanz Expires August 15, 2004 [Page 48]
Internet-Draft iris-core February 2004
[14] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[15] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
Newton & Sanz Expires August 15, 2004 [Page 49]
Internet-Draft iris-core February 2004
Informative References
[16] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", RFC 3707, February 2004.
[17] Newton, A. and M. Sanz, "IRIS Domain Registry Schema",
draft-ietf-crisp-iris-dreg-05 (work in progress), October 2002.
[18] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
954, October 1985.
Newton & Sanz Expires August 15, 2004 [Page 50]
Internet-Draft iris-core February 2004
URIs
[19] <http://www.iana.org/assignments/character-sets>
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/
Newton & Sanz Expires August 15, 2004 [Page 51]
Internet-Draft iris-core February 2004
Appendix A. S-NAPTR and IRIS Uses
A.1 An Examples of S-NAPTR with IRIS
This section shows an example use of S-NAPTR [10] 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
use of S-NAPTR offers the following:
1. A means to allow an operator to split out 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 to allow an operator to specify which set of servers are
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 to allow an operator to 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
their 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:
Newton & Sanz Expires August 15, 2004 [Page 52]
Internet-Draft iris-core February 2004
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
Newton & Sanz Expires August 15, 2004 [Page 53]
Internet-Draft iris-core February 2004
of a transition strategy for cohabitation of protocols solving the
problems of CRISP [16].
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 both via the iris-beep protocol and the whois protocol.
The whois application protocol label refers to RFC 954 [18].
Newton & Sanz Expires August 15, 2004 [Page 54]
Internet-Draft iris-core February 2004
Appendix B. Document Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [8].
Newton & Sanz Expires August 15, 2004 [Page 55]
Internet-Draft iris-core February 2004
Appendix C. 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.
C.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 lookup 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 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, searches across multiple indexes in a registry,
etc..., requires a client with special knowledge of the data
relationships contained within a registry.
Therefore IRIS does the following:
o It does specify the basic schema language used by all registries
to specify their schemas.
o It does provide 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. What this leaves is 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. An imposition of
a common relationship when it is not a natural fit is often a
concern and not a benefit.
Newton & Sanz Expires August 15, 2004 [Page 56]
Internet-Draft iris-core February 2004
C.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
"lookup" 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, requiring 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.
C.3 Server Considerations
As mentioned above, IRIS was designed for the directory service needs
of public-facing registries. In this light, there are certain
aspects of more generalized directory services that are a hindrance
in an environment that does not have the same control and safety
considerations of 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 other utility 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 to that of 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
Newton & Sanz Expires August 15, 2004 [Page 57]
Internet-Draft iris-core February 2004
service.
Finally, IRIS is built upon a set of standard technological layers.
This allows service operators the ability to switch in and out
components to meet the needs of their particular environment.
C.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 a partial value queries, queries across
multiple indexes, or multiple queries to a single index, is a
"search".
Lookups are accomplished through the use of 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.
C.5 Entities References, Search Continuations, and Scope
Due to its importance in 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 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 with regard to scope of
entity references or search continuations. The definition of scope
is strictly a function of need by the type of registry and the
Newton & Sanz Expires August 15, 2004 [Page 58]
Internet-Draft iris-core February 2004
allowances given a service operator by that type of registry.
Newton & Sanz Expires August 15, 2004 [Page 59]
Internet-Draft iris-core February 2004
Appendix D. Acknowledgments
The terminology used in this document to describe namespaces and
namespaces of namespaces is now much clearer thanks to the skillful
debating tactics of Leslie Daigle. Previously, it was much more
confusing. In addition, Leslie has provided great insight into the
details of URI's, URN's, and NAPTR/SRV resource records.
Many other technical complexities were proved to be unnecessary by
David Blacka and have been removed. And his IRIS implementation has
helped smooth out the rougher edges.
Newton & Sanz Expires August 15, 2004 [Page 60]
Internet-Draft iris-core February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Newton & Sanz Expires August 15, 2004 [Page 61]
Internet-Draft iris-core February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Newton & Sanz Expires August 15, 2004 [Page 62]
