Network Working Group A. Newton
Internet-Draft VeriSign, Inc.
Expires: February 12, 2003 August 14, 2002
Internet Registry Information Service (IRIS)
draft-ietf-crisp-iris-core
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 February 12, 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 February 12, 2003 [Page 1]
Internet-Draft iris August 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
2. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
2.1 Protocol Identification . . . . . . . . . . . . . . . . . . 6
2.2 Request Format . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 <serviceInquiry> Request . . . . . . . . . . . . . . . . . . 7
2.2.2 <registrySearch> Request . . . . . . . . . . . . . . . . . . 7
2.3 Response Format . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 <messsageStatus> Response . . . . . . . . . . . . . . . . . 7
2.3.2 <serviceResult> Response . . . . . . . . . . . . . . . . . . 8
2.3.3 <registryResult> Response . . . . . . . . . . . . . . . . . 8
3. Extension Framework . . . . . . . . . . . . . . . . . . . . 10
3.1 Derived Elements . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Registry Identifier Requirements . . . . . . . . . . . . . . 11
3.3 Entity Classes . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Names of Entities . . . . . . . . . . . . . . . . . . . . . 12
3.5 References to Entities . . . . . . . . . . . . . . . . . . . 12
4. URI Requirements . . . . . . . . . . . . . . . . . . . . . . 13
5. Database Serialization . . . . . . . . . . . . . . . . . . . 14
6. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 17
7. Internationalization Considerations . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . 25
References . . . . . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . 27
A. Document Terminology . . . . . . . . . . . . . . . . . . . . 28
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
C. Considerations on XML-based RPC's . . . . . . . . . . . . . 30
Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
Newton Expires February 12, 2003 [Page 2]
Internet-Draft iris August 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 [2], XML Schema notation as
described in [4] and [5], and XML Namespaces as described in [3].
It is important to note that XML is case sensitive. XML
specifications and examples provided in this document MUST be
interpreted in the exact character case presented to develop a
conforming implementation.
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 query elements and result elements.
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
Newton Expires February 12, 2003 [Page 3]
Internet-Draft iris August 2002
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
continuation. An entity URI indicates specific knowledge about an
individual entity, and a search continuation allows for distributed
searches. Both types may span differing registry types and
instances. No assumptions or specifications are made about roots,
bases, or meshes of entities.
Finally, the IRIS framework attempts to be transport neutral.
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, 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 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.
Newton Expires February 12, 2003 [Page 4]
Internet-Draft iris August 2002
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
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[5].
Newton Expires February 12, 2003 [Page 5]
Internet-Draft iris August 2002
2. Protocol Description
Each protocol data unit MUST be one and only one complete and valid
XML instance. The XML instance MUST contain either one request
element or one response element.
No requirements are made concerning the synchronization of the
request and the response in this document. However, a transport
mapping of IRIS MAY make such requirements if necessary. In
addition, no methods are provided in this document for session or
connection creation or termination; a transport mapping of IRIS MAY
make such requirements if necessary.
The following description of the protocol does not describe every
detailed aspect necessary for implementation. While reading these
following sections, please reference Section 6 for needed details on
the formal XML specification.
2.1 Protocol Identification
The root element of all IRIS XML instances must be <iris>. This
element identifies the start of the IRIS elements, the XML namespace
used as the identifier for IRIS, and the location of the schema.
This element and the associated closing tag MUST be applied to all
requests and responses sent by both clients and servers.
An example:
<iris 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">
</iris>
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,
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[3] 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 February 12, 2003 [Page 6]
Internet-Draft iris August 2002
2.2 Request Format
A <request> element holds children representing the different
requests that can be made from a client to a server.
2.2.1 <serviceInquiry> Request
The <serviceInquiry> element enables the client to query for a list
of registry identifiers.
2.2.2 <registrySearch> Request
The <registrySearch> element enables a client to query a particular
registry identified by its registry ID. It may have two element
types as children: <lookupEntity> and <query>.
The children of the <lookupEntity> element are the <entityName> and
<entityClass> elements. The 'registryID' attribute is the registry
identifier for the registry type in which the lookup operation is to
take place. The <entityClass> element MUST contain the token
identifying the index for which the lookup operation is to take
place, and the <entityName> element MUST contain 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.
2.3 Response Format
The <response> element holds children of the different response
types returned from a server to a client.
2.3.1 <messsageStatus> Response
The <messsageStatus> element MUST be returned to the client in
response to any errors that would have disabled the processing of
the corresponding request.
The <messsageStatus> MUST contain one of these child elements:
o <invalidXML> MUST be the response if the server is unable to
correctly parse the corresponding request according to the rules
of [5] and [4].
o <systemError> MUST be the response if the server is unable to
process the corresponding request for any other reason.
Newton Expires February 12, 2003 [Page 7]
Internet-Draft iris August 2002
2.3.2 <serviceResult> Response
The <serviceResult> element is a response to the <serviceInquiry>.
This element MUST contain child elements of <registryID>. The
contents of each child MUST contain one registry identifier. The
<serviceResult> element MUST contain a <registryID> child element
for each registry type for which the server allows queries.
2.3.3 <registryResult> Response
The <registryResult> element is a response to a <registrySearch>
request.
The children MUST be one 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.
o The contents of <entityURI> is a URI. This element notifies the
client of a reference to an entity. The URI SHOULD be an IRIS
URI. Resolution of the URI is OPTIONAL by the client.
o The <searchContinuation> element children MUST contain one
<hostReference> element and one <registrySearch> element.
Registry schemas MAY derive a new type from <hostReference> to
match transport protocol needs.
o The following error elements:
* <insufficientResources> - the corresponding query requires
resources unobtainable by the server.
* <invalidName> - a name given in a query is not syntactically
correct.
* <invalidSearch> - parameters of the corresponding query are
not semantically meaningful.
* <limitExceeded> - the corresponding query requires more
resources than allowed.
* <nameNotFound> - the name given in a query does not match a
known entity.
* <permissionDenied> - the authentication given does not allow
access to a specific result entry. This is not the same as
denying access to all <registryResult> responses because of
Newton Expires February 12, 2003 [Page 8]
Internet-Draft iris August 2002
failed authentication.
* A derivative of <genericCode>.
Newton Expires February 12, 2003 [Page 9]
Internet-Draft iris August 2002
3. Extension Framework
Because the IRIS schema defines no useful query types, no registry
structure, and no result types, it is useless 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.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 MUST appear in an XML instance. Registry schemas derive
from this element to define the queries allowed.
o <result> - as defined this element contains no content and has no
valid attributes. It is abstract and therefore only derivatives
of it MUST appear in an XML instance. 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. Registry schemas MUST derive from this element and MUST
NOT use it as it is an abstract element. It MAY contain the
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.
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.
o <hostReference> - as defined this element contains a <scheme>,
<host>, and <port> elements. Derivations SHOULD extend the
content to include information necessary establishing sessions by
Newton Expires February 12, 2003 [Page 10]
Internet-Draft iris August 2002
lower layer protocols, but MUST NOT restrict derivations to
content less than what is defined.
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[8].
This is a restriction on XML_NS[3], which specifies an XML namespace
identifier is any valid URI[7].
When possible, registry identifiers SHOULD be URN's defined by
XML_URN[13]. 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[13].
In certain circumstances when registry identifiers are URN's defined
by XML_URN[13] 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. The use
of this abbreviation MUST be specifically noted for the set of
conditions where it may be used, otherwise the full URN MUST be
used. These circumstances and conditions MUST be specified in other
sections of this document and other documents related to IRIS where
it is used.
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 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 "nameServer" and "network" classes. The entity
"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.
Newton Expires February 12, 2003 [Page 11]
Internet-Draft iris August 2002
IRIS defines one default entity class of "QUERY" which MAY NOT be
redefined. This 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. When used in URI's
(see Section 4), this is a type of boot-strapping procedure.
Therefore, the resolution of "iris://com/dreg1/QUERY/registrars" may
result in the list of registrars currently registering domains. The
set of canned queries are not specified by IRIS.
3.4 Names of Entities
The names of entities in a registry schema MUST be of type
normalizedString defined by XML_SD[4]. 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
SHOULD attach the attribute of "thisEntityURI" with the datatype of
anyURI as specified by XML_SD[4]. This aids clients in understanding
which parts of a result set represent an entity. The URI value in
the XML instance SHOULD be an IRIS URI.
3.5 References to Entities
The element <entityURI> allows references to entities in result
sets, either as a direct child of <registryResult> 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.
Newton Expires February 12, 2003 [Page 12]
Internet-Draft iris August 2002
4. URI Requirements
IRIS does not have single URI definition because of the dependencies
on a URI by the mapping between IRIS and a transport protocol.
However, any valid IRIS URI definition MUST meet the following
requirements:
o Using the layout form syntax of RFC2396[7], each IRIS URI MUST
contain a <query> component within its <schema-specific-part>
component. The <query> component MUST be composed of the registry
identifier, a '/' (slash) character, the entity class, a '/'
(slash) character, and the name of an entity within the registry.
The layout form syntax of the <query> component MUST be:
<registry-id>/<entity-class>/<entity-name>
o The URI MUST be an absolute URI, therefore the scheme component
is always present.
o The URI MUST contain the <query> URI component as defined above.
This component MUST contain the <registry-id> component, the
<entity-class> component, and the <entity-name> component and
therefore MUST always be an IRIS entity reference.
o The <registry-id> component MAY be abbreviated according to
Section 3.2.
o Each transport mapping MUST define a URI scheme. The scheme name
MAY NOT be used by other IRIS transport mappings.
Newton Expires February 12, 2003 [Page 13]
Internet-Draft iris August 2002
5. Database Serialization
A database of IRIS entities can be serialized to file storage with
XML[2] using the IRIS defined <irisSerialization> element. This
element MUST only contain children which are a derivative of the
<result> element, which SHOULD be elements describing entities.
Because fragmentation is not defined in URI's for XML media
types[14], the "file:" URI scheme cannot be safely used for
serialization of entity URI's. Therefore, serialization of IRIS
entity references SHOULD use the <serializedEntityURI> element
instead of the <entityURI> element. This element is a derivative of
the <entityURI> element. It contains the REQUIRED attributes
"registryID", "entityClass", and "entityName". These attributes MUST
be used to denote the unique identification of an entity. In
addition, the OPTIONAL attribute "fileName" may also be used to
specify the name of a file where the entity can be found.
The actual content of the <serializedEntityURI> element MUST conform
to the datatype of anyURI. A serialization process SHOULD attempt to
formulate a valid IRIS URI to be placed in this element. If an
element describing an entity contains the "thisEntityURI" attribute
as specified in Section 3.4, the value of this URI should be equal
to the value of the URI in any <serializedEntityURI> element
referring to it.
The following is an example of serialized IRIS.
<?xml version="1.0"?>
<irisSerialization xmlns="urn:ietf:params:xml:ns:iris1"
xmlns:iris="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" >
<dreg:domain
xmlns="urn:ietf:params:xml:ns:dreg1"
xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
xsi:schemaLocation="urn:ietf:params:xml:ns:dreg1 dreg.xsd"
thisEntityURI="iris://com/dreg1/domainHandle/tcs-com-1" >
<domainName>thecobblershoppe.com</domainName>
<nameServers>
<iris:serializedEntityURI
registryID="dreg1"
entityClass="hostHandle"
entityName="research7"
fileName="iris-out.xml">
iris://com/dreg1/hostHandle/research7
</iris:serializedEntityURI>
Newton Expires February 12, 2003 [Page 14]
Internet-Draft iris August 2002
<iris:serializedEntityURI
registryID="dreg1"
entityClass="hostHandle"
entityName="nsol184"
fileName="iris-out.xml">
iris://com/dreg1/hostHandle/nso1184
</iris:serializedEntityURI>
</nameServers>
<holder>
<contactHandle>beb140</contactHandle>
<commonName>
Bill Eckels
</commonName>
<organization>
The Cobbler Shoppe
</organization>
<e-mail>
bille@bjmk.com
</e-mail>
<address>
21 North Main Street
</address>
<city>
Britt
</city>
<region>
IA
</region>
<postalCode>
50423
</postalCode>
<country>
US
</country>
<phone>
515-843-3521
</phone>
</holder>
<registry>
<iris:serializedEntityURI
registryID="dreg1"
entityClass="contactHandle"
entityName="VGRS"
fileName="iris-out1.xml">
iris://com/dreg1/contactHandle/VGRS
</iris:serializedEntityURI>
</registry>
</dreg:domain>
Newton Expires February 12, 2003 [Page 15]
Internet-Draft iris August 2002
<dreg:host
xmlns="urn:ietf:params:xml:ns:dreg1"
xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
xsi:schemaLocation="urn:ietf:params:xml:ns:dreg1 dreg.xsd"
thisEntityURI="iris://com/dreg1/hostHandle/nsol184" >
<hostHandle>nsol184</hostHandle>
<hostName>ns1.netsol.com</hostName>
<ipV4Address>216.168.224.200</ipV4Address>
<iris:serializedEntityURI
registryID="dreg1"
entityClass="contactHandle"
entityName="mak21"
fileName="iris-out.xml">
iris://com/dreg1/contactHandle/mak21
</iris:serializedEntityURI>
</dreg:host>
</irisSerialization>
Newton Expires February 12, 2003 [Page 16]
Internet-Draft iris August 2002
6. 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="iris">
<complexType>
<choice>
<element name="request"
type="iris:requestType"
minOccurs="0" maxOccurs="1" />
<element name="response"
type="iris:responseType"
minOccurs="0" maxOccurs="1" />
</choice>
</complexType>
</element>
<complexType name="requestType">
<sequence>
<element name="serviceInquiry"
type="iris:serviceInquiryType"
minOccurs="0" maxOccurs="1" />
<element name="registrySearch"
type="iris:registrySearchType"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="serviceInquiryType" />
<complexType name="registrySearchType" >
<choice>
<element name="lookupEntity"
type="iris:lookupEntityType" />
Newton Expires February 12, 2003 [Page 17]
Internet-Draft iris August 2002
<element ref="iris:query" />
</choice>
</complexType>
<complexType name="queryType"/>
<element name="query"
type="iris:queryType"
abstract="true" />
<simpleType name="entityClassType">
<restriction base="token">
</restriction>
</simpleType>
<element name="entityClass"
type="iris:entityClassType" />
<simpleType name="entityURIType">
<restriction base="anyURI" />
</simpleType>
<simpleType name="thisEntityURIType">
<restriction base="anyURI" />
</simpleType>
<simpleType name="baseentityClassType">
<restriction base="iris:entityClassType">
<enumeration value="QUERY" />
</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="responseType">
<sequence>
<element name="messageStatus"
type="iris:messageStatusType"
Newton Expires February 12, 2003 [Page 18]
Internet-Draft iris August 2002
minOccurs="0" maxOccurs="1" />
<element name="serviceResult"
type="iris:serviceResultType"
minOccurs="0" maxOccurs="1" />
<element name="registryResult"
type="iris:registryResultType"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="messageStatusType" >
<sequence>
<choice>
<element name="invalidXML"
type="iris:codeType"
minOccurs="0" maxOccurs="1" />
<element name="systemError"
type="iris:codeType"
minOccurs="0" maxOccurs="1" />
</choice>
</sequence>
</complexType>
<complexType name="codeType">
<sequence minOccurs="0" maxOccurs="1">
<element name="explanation" type="string" />
<element name="language" type="language" />
</sequence>
</complexType>
<complexType name="serviceResultType" >
<sequence>
<element name="registryID"
minOccurs="1" maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension base="anyURI">
<attribute name="location" type="anyURI"
use="required" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
<element name="entityURI"
type="iris:entityURIType" />
Newton Expires February 12, 2003 [Page 19]
Internet-Draft iris August 2002
<complexType name="seeAlsoType">
<sequence>
<element ref="iris:entityURI"
minOccurs="1" maxOccurs="unbounded" />
</sequence>
</complexType>
<element name="seeAlso" type="iris:seeAlsoType" />
<complexType name="registryResultType" >
<sequence>
<element ref="iris:result"
minOccurs="0" maxOccurs="unbounded" />
<element ref="iris:entityURI"
minOccurs="0" maxOccurs="unbounded" />
<element name="searchContinuation"
minOccurs="0" maxOccurs="unbounded"
type="iris:searchContinuationType" />
<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" />
<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" />
<element name="result"
type="iris:resultType"
abstract="true" />
<complexType name="searchContinuationType">
<sequence>
Newton Expires February 12, 2003 [Page 20]
Internet-Draft iris August 2002
<element ref="iris:hostReference"
minOccurs="1" maxOccurs="1" />
<element name="registrySearch"
type="iris:registrySearchType"
minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
<complexType name="hostReferenceType">
<sequence>
<element name="scheme" type="string"
minOccurs="1" maxOccurs="1" />
<element name="host" type="string"
minOccurs="1" maxOccurs="1" />
<element name="port" type="positiveInteger"
minOccurs="1" maxOccurs="1" />
</sequence>
</complexType>
<element name="hostReference"
type="iris:hostReferenceType" />
<element name="genericCode" type="iris:codeType"
abstract="true" />
<complexType name="serializedEntityURIType">
<simpleContent>
<extension base="iris:entityURIType">
<attribute name="registryID"
type="anyURI" use="required" />
<attribute name="entityClass"
type="iris:entityClassType" use="required" />
<attribute name="entityName"
type="normalizedString" use="required" />
<attribute name="fileName"
type="anyURI" />
</extension>
</simpleContent>
</complexType>
<element name="serializedEntityURI"
type="iris:serializedEntityURIType"
substitutionGroup="iris:entityURI" />
<element name="irisSerialization">
<complexType>
<sequence>
<element ref="iris:result"
minOccurs="1" maxOccurs="unbounded" />
Newton Expires February 12, 2003 [Page 21]
Internet-Draft iris August 2002
</sequence>
</complexType>
</element>
</schema>
Newton Expires February 12, 2003 [Page 22]
Internet-Draft iris August 2002
7. 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 [15] and [9].
Newton Expires February 12, 2003 [Page 23]
Internet-Draft iris August 2002
8. 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 [10], 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[13]. Accordingly, the following URN
will need to be registered with IANA:
urn:ietf:params:xml:ns:iris1
Newton Expires February 12, 2003 [Page 24]
Internet-Draft iris August 2002
9. 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 used to
obtain the registry results SHOULD NOT be used to conduct a
subsequent entity lookup or search continuation.
Newton Expires February 12, 2003 [Page 25]
Internet-Draft iris August 2002
References
[1] Newton, A, "Cross Registry Internet Service Protocol (CRISP)
Requirements", draft-ietf-crisp-requirements-00 (work in
progress), August 2002.
[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] World Wide Web Consortium, "Extensible Stylesheet Language
(XSL) Version 1.0", W3C XSL, November 2000,
<http://www.w3.org/TR/2000/CR-xsl-20001121/>.
[7] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[8] Moats, R., "URN Syntax", RFC 2141, May 1997.
[9] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD
2, October 1994.
[10] Narten, T. and H.T. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, BCP 26,
October 1998.
[11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[12] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[13] Mealling, M, "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-03 (work in progress),
November 2001.
Newton Expires February 12, 2003 [Page 26]
Internet-Draft iris August 2002
[14] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[15] <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@verisignlabs.com
URI: http://www.verisignlabs.com/
Newton Expires February 12, 2003 [Page 27]
Internet-Draft iris August 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[12].
Newton Expires February 12, 2003 [Page 28]
Internet-Draft iris August 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 February 12, 2003 [Page 29]
Internet-Draft iris August 2002
Appendix C. Considerations on XML-based RPC's
Observations have been made about the similarity between IRIS and
XML-based RPC mechanisms, specifically SOAP and XML-RPC. And while
IRIS is not based on a general RPC mechanism, it could easily be
modeled on top of one, especially SOAP. The use of XML-RPC and SOAP
has been weighed, and its pay-off has been found to be
unsatisfactory.
XML-RPC and SOAP are abstraction layers intended to separate a
programmer from the details of protocols and to allow the programmer
to simply use structures and procedures native to a programming
language (or genericized to only the RPC mechanism). The appeal is
that the programmer needs to know very little about implementation
details so that the task of gluing custom logic is inexpensive.
Supposedly, with little to implement, the job can be done faster or
easier.
However, this appeal starts to vanish if the programmer must begin
to go beyond the native language and familiar tools. And the nature
of IRIS defined by the CRISP requirements tend to lead an
implementer down this path. For example, the use of DNS via SRV or
NAPTR resource records to locate authoritative servers is not
available in the interfaces of XML-RPC and SOAP.
Furthermore, XML-RPC and SOAP 1.0 are bound to HTTP. This use, or
misuse, of HTTP violates RFC 3205. It is possible to put XML-RPC or
SOAP 1.1 on other application-transports, but the overwhelming
majority of SOAP and XML-RPC implementations are for HTTP.
Therefore, chances are that an implementer may have to do this work
as well.
In addition, what makes XML-RPC or SOAP much more enticing than
other similar XML-based mechanisms, such as XMOP or ebXML? And why
just XML-based solutions? What makes them better than CORBA or DCOM?
Finally, the intended use of IRIS is more akin to a directory
service than a remote procedure interface. Basing it on a generic
mechanism could easily go from lookup( domain ) to register( domain
). The latter being clearly out-of-scope for CRISP and rightly in
the purview of PROVREG.
Newton Expires February 12, 2003 [Page 30]
Internet-Draft iris August 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 February 12, 2003 [Page 31]
