Network Working Group A. Newton
Internet-Draft VeriSign, Inc.
Expires: May 5, 2003 November 04, 2002
Internet Registry Information Service (IRIS)
draft-ietf-crisp-iris-core-01
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 May 5, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). 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 Expires May 5, 2003 [Page 1]
Internet-Draft iris-core November 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Use of XML . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 General Concepts . . . . . . . . . . . . . . . . . . . . . 3
1.3 Framework Layers . . . . . . . . . . . . . . . . . . . . . 4
1.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Other Documents . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Identification . . . . . . . . . . . . . . . . . 6
3. Exchange Description . . . . . . . . . . . . . . . . . . . 7
3.1 Request Format . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Response Format . . . . . . . . . . . . . . . . . . . . . 7
3.3 Extension Framework . . . . . . . . . . . . . . . . . . . 9
3.3.1 Derived Elements . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Registry Identifier Requirements . . . . . . . . . . . . . 10
3.3.3 Entity Classes . . . . . . . . . . . . . . . . . . . . . . 10
3.3.4 Names of Entities . . . . . . . . . . . . . . . . . . . . 11
3.3.5 References to Entities . . . . . . . . . . . . . . . . . . 12
3.3.6 <result> Derived Elements . . . . . . . . . . . . . . . . 12
3.3.6.1 <serviceIdentification> . . . . . . . . . . . . . . . . . 12
3.3.6.2 <simpleEntity> . . . . . . . . . . . . . . . . . . . . . . 13
4. Database Serialization . . . . . . . . . . . . . . . . . . 14
5. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . 16
6. Internationalization Considerations . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . 26
A. Document Terminology . . . . . . . . . . . . . . . . . . . 27
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28
Full Copyright Statement . . . . . . . . . . . . . . . . . 29
Newton Expires May 5, 2003 [Page 2]
Internet-Draft iris-core November 2002
1. Introduction
The specification outlined in this document is based on the
functional requirements described in CRISP [1].
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 [5], XML Schema notation as
described in [7] and [8], and XML Namespaces as described in [6].
1.2 General Concepts
Each type of Internet registry, such as address, routing, and domain,
are identified by a registry identifier (ID). This registry
identifier 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.
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 is identified by the same URI
that identifies its XML namespace). In order to be useful, a
registry type's specification must extend from this framework.
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 URI and a search
Newton Expires May 5, 2003 [Page 3]
Internet-Draft iris-core November 2002
continuation. An entity URI 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 | routing|
----------------------------
Common-Registry | IRIS |
----------------------------
Application-Transport | beep |
----------------------------
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 referrals, entity references, etc. It
also defines the syntaxes for talking about specific registry
types (using the registry ID's).
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:
registry identifier (ID) - The identifier used to specify a
particular type of registry.
registry type - A registry serving a specific function, such as a
domain registry or an address registry. Each type of registry is
assigned a registry identifier.
registry schema - The definition for a registry type specifying
Newton Expires May 5, 2003 [Page 4]
Internet-Draft iris-core November 2002
the queries, results, and entity classes.
entity class - A group of entities with a common type or common
set of characteristics.
entity name - The identifier used to refer to a single entity
within an entity class.
entity URI - A formal pointer to an entity. This URI contains a
registry ID, entity class, and entity name.
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 [8].
1.5 Other Documents
While this document describes the structures at the core of IRIS,
other aspects of IRIS are described in these related documents: iris-
beep [2], iris-dreg [3], and iris-areg [4].
Newton Expires May 5, 2003 [Page 5]
Internet-Draft iris-core November 2002
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 identifie 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"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd">
</request>
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 [8]. The URI MUST be a valid URI,
and SHOULD resolve if the appropriate network resources are
available.
Versioning of the IRIS protocol is the responsibility of the
application-transport layer but MUST be associated with the XML
namespace [6] URI representing IRIS. A change in this URI indicates
a change of the underlying schema and therefore a new version of the
protocol.
Newton Expires May 5, 2003 [Page 6]
Internet-Draft iris-core November 2002
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 [15] 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 <searchSet> elements. These <searchSet>
elements enables a client to query a particular registry identified
by its registry ID. found in one of it's two children:
<lookupEntity> and <query>.
The children of the <lookupEntity> element contains the <entityName>
and <entityClass> element and has a 'registryID' attribute containing
the registry identifier for the registry type in which the lookup
operation is to take place. The <entityClass> element contains the
token identifying the index for which the lookup operation is to take
place, and the <entityName> element 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.
3.2 Response Format
The <response> element contains <resultSet> elements. These
<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 The content of <entityURI> is a URI. This element notifies the
client of a reference to an entity. The URI SHOULD be an IRIS
Newton Expires May 5, 2003 [Page 7]
Internet-Draft iris-core November 2002
URI. Resolution of the URI is OPTIONAL by the client.
o The <searchContinuation> element children contains an <authority>
element and a <searchSet> element.
When following entity references and search continuations, clients
SHOULD only follow an <entityURI> 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.
The following elements representing error conditions may be returned:
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 <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. This is not the same as
denying access to all <resultSet> responses because of failed
authentication.
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
Newton Expires May 5, 2003 [Page 8]
Internet-Draft iris-core November 2002
client for references contained in the <answer> element. Second, it
distinguishes between results that are a direct result of 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 return results. For instance, clients
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.
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 [7] and XML_SS [8], 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 an XML instances. Registry schemas derive from
this element to define the queries allowed.
o <result> - as defined this element contains no content and has one
valid attribute, "thisEntityURI". It is abstract and therefore
only derivatives of it appear in an XML instances. Registry
schemas derive from this element to define results that may be
returned from a query.
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 <entityClass> - as defined this element represents the identifier
for an entity class. Registry schemas SHOULD derive from this
element or MAY use it directly.
Newton Expires May 5, 2003 [Page 9]
Internet-Draft iris-core November 2002
o <seeAlso> - contains one or more <entityURI> 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 Identifier Requirements
The identifier for a registry 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 [11].
This is a restriction on XML_NS [6], which specifies an XML namespace
identifier is any valid URI [10].
When possible, registry identifiers SHOULD be URN's defined by
XML_URN [16]. 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 [6], they MUST be of the class "ns"
as defined in XML_URN [16].
Case sensitivity of registry ID's is dependent on the namespace
definition of the URN itself. Registry ID's conforming to XML_URN
[16] are case insensitive.
When registry identifiers are URN's defined by XML_URN [16] and the
class component is "ns", they 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", but the full URN "urn:otherOrg:ns:myreg1"
cannot be abbreviated.
This abbreviation MUST NOT be used inside of XML instances in use
with IRIS where XML Schema [7] specifies the use of a URI for schema
identification or where XML_NS [6] 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 with in any given registry type. Their specification in
queries also allows server implementations to quickly narrow search
or lookup scopes to a single index. A registry schema derives the
list of valid entity classes from the <entityClass> element.
For instance, the entity name "10.0.1.1" would refer to separate
entities in the "name-server" and "network" classes. The entity
Newton Expires May 5, 2003 [Page 10]
Internet-Draft iris-core November 2002
"10.0.1.1" in the "nameServer" 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.foo.com", whereas the entity "10.0.1.1" in the "network" class
may refer to the network 10.0.1/24.
IRIS defines two default entity classes of "named-query" and
"service-definition" which MAY NOT be redefined. These entity
classes MUST be valid in all registry types.
The "named-query" class is for the naming of canned queries by
registries. Therefore an entity lookup of a canned query MAY result
in a search continuation on the same registry or a set of predefined
results. When used in URI's, this is a type of boot-strapping
procedure. Therefore, the resolution of "iris://com/dreg1/named-
query/registrars" may result in the list of registrars currently
registering domains. The set of named queries are not specified by
IRIS.
The "service-definition" class is reserved for entities specific to a
particular service instance. It MUST contain an entity named "id"
(see Section 3.3.4 which yields a result of <serviceIdentification>
(see Section 3.3.6.1. 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 [7]. Their use SHOULD be transcribable. 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 [7]. Their use SHOULD be transcribable.
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. "foo.com" can
refer to both the domain foo.com and the host foo.com). However,
this type of conflict SHOULD generally be avoided by the proper use
of entity classes.
When specifying elements that represent entities, registry schemas
must attach the attribute of "thisEntityURI" with the datatype of
anyURI as specified by XML_SD [7]. This aids clients in
understanding which parts of a result set represent an entity. The
Newton Expires May 5, 2003 [Page 11]
Internet-Draft iris-core November 2002
URI value in the XML instance SHOULD be an IRIS URI.
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. However, a registry type SHOULD be consistent with case
sensitivity and SHOULD specify case insensitivity if possible.
3.3.5 References to Entities
The element <entityURI> allows references to entities in result sets,
either as a direct child of <resultSet> or within a more complex
structure that derives from <result>. Registry schemas MUST NOT
derive elements from this element so that clients will have a better
understanding of what is and what isn't an entity reference. This is
especially useful to clients when dealing with XML conversion
technologies such as XPath.
The <entityURI> element can have the two attributes "displayName" and
"language". These are provided so that servers may provide to
clients a more human friendly meaning to the entity reference. This
is often useful to user navigating referral structures.
3.3.6 <result> Derived Elements
The base IRIS framework does contain two elements directly derived
from the <result> element for use by any registry type.
3.3.6.1 <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 <eMail> - This optional element contains an email address of the
operator of the service instance.
o <phone> - This optional element contains the phone number of the
operator of the service instance.
Newton Expires May 5, 2003 [Page 12]
Internet-Draft iris-core November 2002
o <seeAlso> - See Section 3.3.1 for its definition.
3.3.6.2 <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 make it a referent 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. 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 scenarios thus calling into question the
need for a new registry type.
Newton Expires May 5, 2003 [Page 13]
Internet-Draft iris-core November 2002
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 [15] 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 [5] using the IRIS defined <serialization> element. This element
contains <result> element derivatives, <searchContinuation> elements,
and <serializedNamedQuery> elements
Derivatives of the <result> element are entities. Servers loading
these entities MUST place the entity in the entity class specified by
the elements 'thisEntityURI' attribute 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 attribute
thisEntityURI="iris://example.authority/example.registry/foo/one" and
a child element <bar>two</bar>, the server is enter that entity into
the entity class "foo" as named "one" and the entity class "bar" as
named "two".
Servers loading entities as serialized derivatives of the <result>
element MAY translate the authority component of the URI specified in
the 'thisEntityURI' attribute. Server will likely need to do this if
the authority for the entity has changed.
<searchContinuation> elements allow for the serialization of static
referrals. When this element appears as a child of the
<serialization> element, it MUST have the "thisEntityURI" attribute.
<serializedNamedQuery> element allows for the specification of static
results for a named query. This element contains a <resultSet>
element holding the results to be returned by the server if the named
query is requested. The server MUST place the named query in the
"named-query" entity class.
As mentioned above, there may be times when a server needs to
translate the authority section of an IRIS URI when loading entities.
The <serializedEntityURI> element is provided for conditions where
this must also be done for entity references. During
deserialization, servers MAY change the authority component of an
Newton Expires May 5, 2003 [Page 14]
Internet-Draft iris-core November 2002
IRIS URI contained within the <serializedEntityURI> element to be an
authority for which the server answers queries. During
serialization, servers and their related processes MUST use the
<serializedEntityURI> element instead of the <entityURI> element for
entity references in which the referent of the URI is an entity for
which the server answers queries. The authority component contained
within an IRIS URI in the <entityURI> element SHOULD NOT be altered
during serialization or deserialization.
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"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
<serviceIdentification
thisEntityURI="iris://com/dreg1/service-definition/id" >
<authorities>
<authority> com </authority>
<authority> net </authority>
</authorities>
<eMail>
davidb@verisignlabs.com
</eMail>
<seeAlso>
<entityURI>
iris://com/dreg1/service-definition/notice
</entityURI>
</seeAlso>
</serviceIdentification>
<simpleEntity
thisEntityURI="iris://com/dreg1/service-definition/notice">
<property name="legal" language="en">
Please use the net wisely! We are required to tell
you this.
</property>
</simpleEntity>
</iris:serialization>
Newton Expires May 5, 2003 [Page 15]
Internet-Draft iris-core November 2002
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>
<element name="request">
<complexType>
<sequence>
<element name="searchSet"
type="iris:searchSetType"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element name="response">
<complexType>
<sequence>
<element name="resultSet"
type="iris:resultSetType"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<complexType name="searchSetType" >
<choice>
<element name="lookupEntity"
type="iris:lookupEntityType" />
<element ref="iris:query" />
</choice>
</complexType>
<complexType name="queryType"/>
Newton Expires May 5, 2003 [Page 16]
Internet-Draft iris-core November 2002
<element name="query"
type="iris:queryType"
abstract="true" />
<simpleType name="entityClassType">
<restriction base="token">
</restriction>
</simpleType>
<element name="entityClass"
type="iris:entityClassType" />
<simpleType name="baseentityClassType">
<restriction base="iris:entityClassType">
<enumeration value="named-query" />
<enumeration value="service-definition" />
</restriction>
</simpleType>
<element name="baseentityClass"
type="iris:baseentityClassType"
substitutionGroup="iris:entityClass" />
<complexType name="lookupEntityType" >
<sequence>
<element name="entityName" type="token" />
<element ref="iris:entityClass" />
</sequence>
<attribute name="registryID"
type="anyURI" use="required" />
</complexType>
<complexType name="codeType">
<sequence minOccurs="0" maxOccurs="1">
<element name="explanation" type="string" />
<element name="language" type="language" />
</sequence>
</complexType>
<complexType name="entityURIType">
<simpleContent>
<extension base="anyURI">
<attribute name="displayName" type="string" />
<attribute name="language" type="language" />
</extension>
</simpleContent>
</complexType>
Newton Expires May 5, 2003 [Page 17]
Internet-Draft iris-core November 2002
<element name="entityURI"
type="iris:entityURIType" />
<complexType name="seeAlsoType">
<sequence>
<element ref="iris:entityURI"
minOccurs="1" maxOccurs="unbounded" />
</sequence>
</complexType>
<element name="seeAlso" type="iris:seeAlsoType" />
<complexType name="resultSetType" >
<sequence>
<element name="answer"
minOccurs="1" maxOccurs="1">
<complexType>
<sequence>
<element ref="iris:result"
minOccurs="0" maxOccurs="unbounded" />
<element ref="iris:entityURI"
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="0" maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element name="insufficientResources"
minOccurs="0" maxOccurs="1"
type="iris:codeType" />
<element name="invalidName"
minOccurs="0" maxOccurs="1"
type="iris:codeType" />
<element name="invalidSearch"
minOccurs="0" maxOccurs="1"
type="iris:codeType" />
<element name="limitExceeded"
minOccurs="0" maxOccurs="1"
type="iris:codeType" />
Newton Expires May 5, 2003 [Page 18]
Internet-Draft iris-core November 2002
<element name="nameNotFound"
minOccurs="0" maxOccurs="1"
type="iris:codeType" />
<element name="permissionDenied"
minOccurs="0" maxOccurs="1"
type="iris:codeType" />
<element ref="iris:genericCode"
minOccurs="0" maxOccurs="1" />
</sequence>
</complexType>
<complexType name="resultType">
<attribute name="thisEntityURI"
use="required"
type="anyURI" />
</complexType>
<element name="result"
type="iris:resultType"
abstract="true" />
<complexType name="searchContinuationType">
<sequence>
<element name="authority" type="token"
minOccurs="1" maxOccurs="1" />
<element name="searchSet"
type="iris:searchSetType"
minOccurs="1" maxOccurs="1"/>
</sequence>
<attribute name="thisEntityURI"
type="anyURI" />
</complexType>
<element name="searchContinuation"
type="iris:searchContinuationType" />
<element name="genericCode" type="iris:codeType"
abstract="true" />
<element name="serializedEntityURI"
type="iris:entityURIType"
substitutionGroup="iris:entityURI" />
<complexType name="serializedNamedQueryType">
<sequence>
<element name="resultSet"
type="iris:resultSetType" />
</sequence>
Newton Expires May 5, 2003 [Page 19]
Internet-Draft iris-core November 2002
<attribute name="registryID" type="anyURI"
use="required" />
<attribute name="entityName" type="token"
use="required" />
</complexType>
<element name="serialization">
<complexType>
<choice
minOccurs="1" maxOccurs="unbounded">
<element ref="iris:result" />
<element ref="iris:searchContinuation" />
<element name="serializedNamedQuery"
type="iris:serializedNamedQueryType" />
</choice>
</complexType>
</element>
<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="eMail" type="string"
minOccurs="0" maxOccurs="1" />
<element name="phone" type="string"
minOccurs="0" maxOccurs="1" />
<element ref="iris:seeAlso"
minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="serviceIdentification"
type="iris:serviceIdentificationType"
substitutionGroup="iris:result" />
<complexType name="simpleEntityType">
<complexContent>
Newton Expires May 5, 2003 [Page 20]
Internet-Draft iris-core November 2002
<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" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="simpleEntity"
type="iris:simpleEntityType"
substitutionGroup="iris:result" />
</schema>
Newton Expires May 5, 2003 [Page 21]
Internet-Draft iris-core November 2002
6. Internationalization Considerations
IRIS is represented in XML, which provides native support for
encoding information using the double-byte Unicode character set and
its more compact representations including UTF-8. Compliant XML
processors are required to understand both UTF-8 and raw Unicode
character sets; XML also includes a provision for identifying other
character sets through use of an "encoding" attribute in an <?xml?>
processing instruction. The complete list of character set encoding
identifiers is maintained by IANA and is described in [17] and [12].
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 [7] to aid clients in the
localization process. See Section 3.3.6.2 as an example.
Newton Expires May 5, 2003 [Page 22]
Internet-Draft iris-core November 2002
7. IANA Considerations
XML schemas require a URI for unique identification. Schemas MUST be
registered to ensure URI uniqueness, but the IETF does not currently
have a recommended repository for the registration of XML schemas.
This document uses URNs to describe XML namespaces and XML schemas.
IANA SHOULD maintain a registry of XML namespace and schema URI
assignments. Per policies described in [13], URI assignment requests
SHOULD be reviewed by a designated expert, and values SHOULD be
assigned only as a result of standards action taken by the IESG.
This document makes use of a proposed XML namespace and schema
registry specified in XML_URN [16]. Accordingly, the following URN
will need to be registered with IANA:
urn:ietf:params:xml:ns:iris1
Newton Expires May 5, 2003 [Page 23]
Internet-Draft iris-core November 2002
8. 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 Expires May 5, 2003 [Page 24]
Internet-Draft iris-core November 2002
References
[1] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", draft-ietf-crisp-requirements-00 (work in
progress), August 2002.
[2] Newton, A., "Using the Internet Registry Information Service
(IRIS) over the Blocks Extensible Exchange Protocol (BEEP)",
draft-ietf-crisp-iris-beep-01 (work in progress), October 2002.
[3] Newton, A., "IRIS Domain Registry Schema", draft-ietf-crisp-
iris-dreg-01 (work in progress), October 2002.
[4] Newton, A., "IRIS Address Registry Schema", draft-ietf-crisp-
iris-areg-01 (work in progress), October 2002.
[5] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
xml-19980210>.
[6] World Wide Web Consortium, "Namespaces in XML", W3C XML
Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-
names-19990114>.
[7] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
xmlschema-2-20010502/>.
[8] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
xmlschema-1-20010502/>.
[9] World Wide Web Consortium, "Extensible Stylesheet Language
(XSL) Version 1.0", W3C XSL, November 2000, <http://www.w3.org/
TR/2000/CR-xsl-20001121/>.
[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[11] Moats, R., "URN Syntax", RFC 2141, May 1997.
[12] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD
2, October 1994.
[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October
1998.
Newton Expires May 5, 2003 [Page 25]
Internet-Draft iris-core November 2002
[14] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[16] Mealling, M., "The IETF XML Registry", draft-mealling-iana-
xmlns-registry-03 (work in progress), November 2001.
[17] <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>
Author's Address
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@ecotroph.net
URI: http://www.verisignlabs.com/
Newton Expires May 5, 2003 [Page 26]
Internet-Draft iris-core November 2002
Appendix A. 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 [15].
Newton Expires May 5, 2003 [Page 27]
Internet-Draft iris-core November 2002
Appendix B. Acknowledgements
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.
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 Expires May 5, 2003 [Page 28]
Internet-Draft iris-core November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 assigns.
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
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 Expires May 5, 2003 [Page 29]
