view Side-By-Side changes

Network Working Group                                          A. Newton
Internet-Draft                                            VeriSign, Inc.
Expires: February 12, May 5, 2003                               August 14,                                   November 04, 2002


              Internet Registry Information Service (IRIS)
                       draft-ietf-crisp-iris-core
                     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.

   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. 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, 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 February 12, May 5, 2003                  [Page 1]

Internet-Draft                    iris                       August                  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
   2.    Protocol Description
   1.5     Other Documents  . . . . . . . . . . . . . . . . . . . .  6
   2.1 .  5
   2.      Protocol Identification  . . . . . . . . . . . . . . . . . .  6
   2.2   Request Format . . . .
   3.      Exchange Description . . . . . . . . . . . . . . . . . . .  7
   2.2.1 <serviceInquiry>
   3.1     Request Format . . . . . . . . . . . . . . . . . .  7
   2.2.2 <registrySearch> Request . . . . . . . . . . . . . . . . . .  7
   2.3
   3.2     Response Format  . . . . . . . . . . . . . . . . . . . . . .  7
   2.3.1 <messsageStatus> Response  . . . . . . . . . . . . . . . . .  7
   2.3.2 <serviceResult> Response . .
   3.3     Extension Framework  . . . . . . . . . . . . . . . .  8
   2.3.3 <registryResult> Response . . .  9
   3.3.1   Derived Elements . . . . . . . . . . . . . .  8
   3.    Extension Framework . . . . . . .  9
   3.3.2   Registry Identifier Requirements . . . . . . . . . . . . . 10
   3.1   Derived Elements
   3.3.3   Entity Classes . . . . . . . . . . . . . . . . . . . . . . 10
   3.2   Registry Identifier Requirements . . . .
   3.3.4   Names of Entities  . . . . . . . . . . 11
   3.3   Entity Classes . . . . . . . . . . 11
   3.3.5   References to Entities . . . . . . . . . . . . . 11
   3.4   Names of Entities . . . . . 12
   3.3.6   <result> Derived Elements  . . . . . . . . . . . . . . . . 12
   3.5   References to Entities . .
   3.3.6.1 <serviceIdentification>  . . . . . . . . . . . . . . . . . 12
   4.    URI Requirements
   3.3.6.2 <simpleEntity> . . . . . . . . . . . . . . . . . . . . . . 13
   5.
   4.      Database Serialization . . . . . . . . . . . . . . . . . . . 14
   6.
   5.      Formal XML Syntax  . . . . . . . . . . . . . . . . . . . . . 17
   7. 16
   6.      Internationalization Considerations  . . . . . . . . . . . . 23
   8. 22
   7.      IANA Considerations  . . . . . . . . . . . . . . . . . . . . 24
   9. 23
   8.      Security Considerations  . . . . . . . . . . . . . . . . . . 25 24
           References . . . . . . . . . . . . . . . . . . . . . . . . . 26 25
           Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 26
   A.      Document Terminology . . . . . . . . . . . . . . . . . . . . 28 27
   B.      Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
   C.    Considerations on XML-based RPC's  . . . . . . . . . . . . . 30 28
           Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 29




















Newton                     Expires February 12, May 5, 2003                  [Page 2]

Internet-Draft                    iris                       August                  iris-core                  November 2002


1. Introduction

   The specification outlined in this document is based on the
   functional requirements described in CRISP[1]. 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], [5], XML Schema notation as
   described in [4] [7] and [5], [8], 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. [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 query elements queries and result elements. 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


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



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 types referrals 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...          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.



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



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[5]. 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 February 12, May 5, 2003                  [Page 5]

Internet-Draft                    iris                       August                  iris-core                  November 2002


2. Protocol Description

   Each protocol data unit MUST be one and only one complete and valid
   XML instance. Identification

   The XML instance MUST contain either one request root element or one response element.

   No requirements are made concerning the synchronization of the all 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 instances MUST be <request>.  The
   root element of all IRIS response XML instances must MUST be <iris>. This
   element identifies <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.
   This element
   These elements and the associated closing tag MUST be applied to all
   requests and responses sent by both clients and servers.

   An abstracted example: 

   <iris

   <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">
   </iris>
   </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 [5]. [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[3]
   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 February 12, May 5, 2003                  [Page 6]

Internet-Draft                    iris                       August                  iris-core                  November 2002


2.2 Request Format

   A <request> element holds children representing


3. Exchange Description

   This section describes the different
   requests that can be made from a client to a server.

2.2.1 <serviceInquiry> Request request and response exchanges of the
   protocol.  The <serviceInquiry> element enables descriptions contained within this section refer to
   XML elements and attributes and their relation to the client 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 query for a list
   describe the specification outside the scope of registry identifiers. 

2.2.2 <registrySearch> the formal XML
   syntax.  While reading this section, please reference Section 5 for
   needed details on the formal XML syntax.

3.1 Request

   The <registrySearch> Format

   A <request> element contains <searchSet> elements.  These <searchSet>
   elements enables a client to query a particular registry identified
   by its registry ID. It may have  found in one of it's two element
   types as children:
   <lookupEntity> and <query>.

   The children of the <lookupEntity> element are contains the <entityName>
   and <entityClass> elements. The element and has a 'registryID' attribute is containing
   the registry identifier for the registry type in which the lookup
   operation is to take place.  The <entityClass> element MUST contain contains the
   token identifying the index for which the lookup operation is to take
   place, and the <entityName> element MUST contain contains the name of the entity
   to lookup.

   The <query> element is abstract and MAY NOT 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  This derivation mechanism is
   described in Section 3.3.

3.2 Response Format

   The <response> element holds children of the different response
   types returned from a server contains <resultSet> elements.  These
   <resultSet> elements are responses 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 <searchSet> 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
   contents 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 this element MUST contain child an <answer> element, an optional
   <additional> element, and error elements of <registryID>. if applicable.

   The
   contents children 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> <answer> element is a response to a <registrySearch>
   request.

   The children MUST be one are of the following types:

   o  <result> is an abstract element and MAY NOT 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 contents 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 MUST contain one
      <hostReference> contains an <authority>
      element and one <registrySearch> element.
      Registry schemas MAY derive a new type from <hostReference> to
      match transport protocol needs. 

   o  The <searchSet> element.

   When following error elements: 

      *  <insufficientResources> - the corresponding query requires
         resources unobtainable by entity references and search continuations, clients
   SHOULD only follow an <entityURI> or <searchContinuation> response
   once.  Failure to do so may result in the server. 

      *  <invalidName> - a name given client process getting
   stuck in a never-ending query is 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 <registryResult> <resultSet> responses because of


Newton                 Expires February 12, 2003                [Page 8]

Internet-Draft                    iris                       August 2002 failed
      authentication. 

      *

   o  A derivative of <genericCode>. <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 February 12, May 5, 2003                  [Page 9] 8]

Internet-Draft                    iris                       August                  iris-core                  November 2002


3.


   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 no useful only one query types, type, no registry
   structure, and no only two stand-alone result types, it is useless of limited
   use by itself.  Extension of IRIS is accomplished through the use a
   base IRIS schema, as defined in XML_SD[4] XML_SD [7] and XML_SS[5], XML_SS [8], and
   extension of it by schemas constructed on top of IRIS. 

3.1

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 MUST appear in an XML instance. instances.  Registry schemas derive from
      this element to define the queries allowed.

   o  <result> - as defined this element contains no content and has no one
      valid attributes. attribute, "thisEntityURI".  It is abstract and therefore
      only derivatives of it MUST appear in an XML instance. 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. Registry schemas MUST derive from this element and MUST
      NOT use it as it is an abstract element.
      <codeType>.  It MAY contain 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.

   o  <seeAlso> - contains one




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.

   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


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[8]. URN [11].

   This is a restriction on XML_NS[3], XML_NS [6], which specifies an XML namespace
   identifier is any valid URI[7]. URI [10].

   When possible, registry identifiers SHOULD be URN's defined by
   XML_URN[13].
   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[3], XML_NS [6], they MUST be of the class "ns"
   as defined in XML_URN[13]. 

   In certain circumstances when 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[13] 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. 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] Schema [7] specifies the use of a URI for schema
   identification or where XML_NS[3] XML_NS [6] specifies the use of a URI for XML
   namespace identification.

3.3

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 "nameServer" "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.


Newton                 Expires February 12, 2003               [Page 11]

Internet-Draft                    iris                       August 2002

   IRIS defines one two default entity class classes of "QUERY" "named-query" and
   "service-definition" which MAY NOT be redefined. This  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. registry or a set of predefined
   results.  When used in URI's
   (see Section 4), URI's, this is a type of boot-strapping
   procedure.  Therefore, the resolution of "iris://com/dreg1/QUERY/registrars" "iris://com/dreg1/named-
   query/registrars" may result in the list of registrars currently
   registering domains.  The set of canned named queries are not specified by
   IRIS.

3.4

   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 MUST be are of type
   normalizedString token defined
   by XML_SD[4]. 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
   SHOULD
   must attach the attribute of "thisEntityURI" with the datatype of
   anyURI as specified by XML_SD[4]. 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.

3.5

   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 <registryResult> <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.











Newton                 Expires February 12, 2003               [Page 12]

Internet-Draft                    iris                       August 2002


4. URI Requirements

   IRIS does not

   The <entityURI> element can have single URI definition because of the dependencies
   on two attributes "displayName" and
   "language".  These are provided so that servers may provide to
   clients a URI by more human friendly meaning to the mapping between entity reference.  This
   is often useful to user navigating referral structures.

3.3.6 <result> Derived Elements

   The base IRIS and a transport protocol.
   However, framework does contain two elements directly derived
   from the <result> element for use by any valid registry type.

3.3.6.1 <serviceIdentification>

   The <serviceIdentification> element is provided to allow IRIS URI definition MUST meet clients
   the ability to reference IRIS service instances.  It contains the
   following
   requirements: elements:

   o  Using the layout form syntax of RFC2396[7], each IRIS URI MUST
      contain  <authorities> - This element contains one or more <authority>
      elements.  Each <authority> element contains a <query> component within its <schema-specific-part>
      component. The <query> URI authority
      component MUST be composed of for which the registry
      identifier, server has results.  While a '/' (slash) character, the entity class, server MAY
      only return a '/'
      (slash) character, and the name partial list of an entity within its authority areas depending on
      operator policy, it MUST return the registry.
      The layout form syntax of authority for which the <query> component MUST be: 
    <registry-id>/<entity-class>/<entity-name> client
      has requested.

   o  The URI MUST be  <eMail> - This optional element contains an absolute URI, therefore email address of the scheme component
      is always present. 

   o  The URI MUST contain
      operator of the <query> URI component as defined above. service instance.

   o  <phone> - This component MUST contain optional element contains the <registry-id> component, phone number of the
      <entity-class> component, and
      operator of the <entity-name> component and
      therefore MUST always be an IRIS entity reference. 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 <registry-id> component MAY be abbreviated according <simpleEntity> element is provided so that service operators may
   make simple additions to
      Section 3.2.

   o  Each transport mapping MUST define other entities without the need for deriving
   entirely new registry types.  Its definition allows service operators
   to make it a URI scheme. referent from other entities (using, for instance, a
   <seeAlso> element).  The scheme <simpleEntity> is meant to represent name
      MAY NOT
   and value pairs of strings, allowing each pair to be used by other IRIS transport mappings. 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 February 12, May 5, 2003                 [Page 13]

Internet-Draft                    iris                       August                  iris-core                  November 2002


5.


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[2]
   XML [5] using the IRIS defined <irisSerialization> <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 only contain children place the entity in the entity class specified by
   the elements 'thisEntityURI' attribute and any entity class which are 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, which SHOULD be elements describing entities.

   Because fragmentation is not defined
   element MAY translate the authority component of the URI specified in URI's
   the 'thisEntityURI' attribute.  Server will likely need to do this if
   the authority for XML media
   types[14], the "file:" URI scheme cannot be safely used entity has changed.

   <searchContinuation> elements allow for the serialization of entity URI's. Therefore, serialization static
   referrals.  When this element appears as a child of IRIS
   entity references SHOULD use the <serializedEntityURI>
   <serialization> element, it MUST have the "thisEntityURI" attribute.

   <serializedNamedQuery> element
   instead of allows for the <entityURI> element. specification of static
   results for a named query.  This element is contains a derivative of <resultSet>
   element holding the <entityURI> element. It contains results to be returned by the REQUIRED attributes
   "registryID", "entityClass", and "entityName". These attributes server if the named
   query is requested.  The server MUST
   be used to denote place the unique identification of an entity. In
   addition, named query in the OPTIONAL attribute "fileName"
   "named-query" entity class.

   As mentioned above, there may also be used times when a server needs to
   specify
   translate the name authority section of a file where the entity can be found. an IRIS URI when loading entities.
   The actual content of the <serializedEntityURI> element MUST conform
   to is provided for conditions where
   this must also be done for entity references.  During
   deserialization, servers MAY change the datatype authority component of anyURI. A serialization process SHOULD attempt to
   formulate a valid an



Newton                     Expires May 5, 2003                 [Page 14]

Internet-Draft                  iris-core                  November 2002


   IRIS URI contained within the <serializedEntityURI> element to be placed in this element. If an
   authority for which the server answers queries.  During
   serialization, servers and their related processes MUST use the
   <serializedEntityURI> element describing an entity contains instead of the "thisEntityURI" attribute
   as specified <entityURI> element for
   entity references in Section 3.4, which the value referent of this URI should be equal
   to the value of URI is an entity for
   which the server answers queries.  The authority component contained
   within an IRIS URI in any <serializedEntityURI> the <entityURI> element
   referring to it. SHOULD NOT be altered
   during serialization or deserialization.

   The following is an example of serialized IRIS.


   <?xml version="1.0"?>
   <irisSerialization xmlns="urn:ietf:params:xml:ns:iris1"


   <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" >

     <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"

     <serviceIdentification
       thisEntityURI="iris://com/dreg1/service-definition/id" >
       <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>
       <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 February 12, May 5, 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                  iris-core                  November 2002


6.


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="iris"> name="request">
       <complexType>
         <choice>
           <element name="request"
             type="iris:requestType"
             minOccurs="0" maxOccurs="1" />
         <sequence>
           <element name="response"
             type="iris:responseType" name="searchSet"
             type="iris:searchSetType"
             minOccurs="0" maxOccurs="1" maxOccurs="unbounded" />
         </choice>
         </sequence>
       </complexType>
     </element>

     <complexType name="requestType">
       <sequence>

     <element name="serviceInquiry"
           type="iris:serviceInquiryType"
           minOccurs="0" maxOccurs="1" /> name="response">
       <complexType>
         <sequence>
           <element name="registrySearch"
           type="iris:registrySearchType" name="resultSet"
             type="iris:resultSetType"
             minOccurs="0" maxOccurs="unbounded" />
         </sequence>
       </complexType>
     </element>

     <complexType name="serviceInquiryType" />

     <complexType name="registrySearchType" name="searchSetType" >
       <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"/>



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="entityURIType">
       <restriction base="anyURI" />
     </simpleType>

     <simpleType name="thisEntityURIType">
       <restriction base="anyURI" />
     </simpleType>

     <simpleType name="baseentityClassType">
       <restriction base="iris:entityClassType">
         <enumeration value="QUERY" 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="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> name="entityURIType">
       <simpleContent>
         <extension base="anyURI">
           <attribute name="location" type="anyURI"
                   use="required" name="displayName" type="string" />
           <attribute name="language" type="language" />
         </extension>
       </simpleContent>
     </complexType>
         </element>
       </sequence>
     </complexType>

     <element name="entityURI"
       type="iris:entityURIType" />




Newton                     Expires February 12, May 5, 2003                 [Page 19] 17]

Internet-Draft                    iris                       August                  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="registryResultType" 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 name="searchContinuation" 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"
           type="iris:searchContinuationType" />
             </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" name="resultType">
       <attribute name="thisEntityURI"
         use="required"
         type="anyURI" />
     </complexType>

     <element name="result"
       type="iris:resultType"
       abstract="true" />

     <complexType name="searchContinuationType"> 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 February 12, May 5, 2003                 [Page 20] 19]

Internet-Draft                    iris                       August                  iris-core                  November 2002


       <attribute name="registryID" type="anyURI"
         use="required" />
       <attribute name="entityName" type="token"
         use="required" />
     </complexType>

     <element ref="iris:hostReference" name="serialization">
       <complexType>
         <choice
           minOccurs="1" maxOccurs="1" maxOccurs="unbounded">
           <element ref="iris:result" />
           <element name="registrySearch"
           type="iris:registrySearchType"
           minOccurs="1" maxOccurs="1"/>
       </sequence> ref="iris:searchContinuation" />
           <element name="serializedNamedQuery"
             type="iris:serializedNamedQueryType" />
         </choice>
       </complexType>
     </element>

     <complexType name="hostReferenceType"> name="serviceIdentificationType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>
             <element name="scheme" type="string" 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="host" name="phone" type="string"
           minOccurs="1"
               minOccurs="0" maxOccurs="1" />
             <element name="port" type="positiveInteger"
           minOccurs="1" ref="iris:seeAlso"
               minOccurs="0" maxOccurs="1" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="hostReference"
       type="iris:hostReferenceType" />

     <element name="genericCode" type="iris:codeType"
       abstract="true" name="serviceIdentification"
       type="iris:serviceIdentificationType"
       substitutionGroup="iris:result" />

     <complexType name="serializedEntityURIType"> 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="iris:entityURIType">
           <attribute name="registryID"
             type="anyURI" use="required" /> base="string">
                     <attribute name="entityClass"
             type="iris:entityClassType" name="name" type="string"
                       use="required" />
                     <attribute name="entityName"
             type="normalizedString" name="language" type="language"
                       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
             </element>
           </sequence>
         </extension>
       </complexContent>
     </complexType>
     </element>

     <element name="simpleEntity"
       type="iris:simpleEntityType"
       substitutionGroup="iris:result" />

   </schema>


























Newton                     Expires February 12, May 5, 2003                 [Page 22] 21]

Internet-Draft                    iris                       August                  iris-core                  November 2002


7.


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 [15]  [17] and [12].

   The application-transport layer MUST define a common set of character
   set encodings to be understood by both client and [9]. 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 February 12, May 5, 2003                 [Page 23] 22]

Internet-Draft                    iris                       August                  iris-core                  November 2002


8.


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 [10], [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[13]. XML_URN [16].  Accordingly, the following URN
   will need to be registered with IANA:

      urn:ietf:params:xml:ns:iris1



































Newton                     Expires February 12, May 5, 2003                 [Page 24] 23]

Internet-Draft                    iris                       August                  iris-core                  November 2002


9.


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 used and
   mechanisms subject to
   obtain the registry results replay attacks SHOULD NOT be used to conduct a
   subsequent entity lookup or search continuation.







































Newton                     Expires February 12, May 5, 2003                 [Page 25] 24]

Internet-Draft                    iris                       August                  iris-core                  November 2002


References

   [1]   Newton, A, 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>.

   [3] <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>.

   [4] <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/>.

   [5] <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/>.

   [6] <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/>.

   [7] <http://www.w3.org/
         TR/2000/CR-xsl-20001121/>.

   [10]  Berners-Lee, T., Fielding, R.T. R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [8]

   [11]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [9]

   [12]  Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD
         2, October 1994.

   [10]

   [13]  Narten, T. and H.T. H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", RFC 2434, BCP 26, October
         1998.

   [11]



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.

   [12]

   [15]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [13]

   [16]  Mealling, M, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-03 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]

   [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@verisignlabs.com anewton@ecotroph.net
   URI:   http://www.verisignlabs.com/




























Newton                     Expires February 12, May 5, 2003                 [Page 27] 26]

Internet-Draft                    iris                       August                  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[12]. RFC2119 [15].














































Newton                     Expires February 12, May 5, 2003                 [Page 28] 27]

Internet-Draft                    iris                       August                  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 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, May 5, 2003                 [Page 30] 28]

Internet-Draft                    iris                       August                  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 Editor function is currently provided by the
   Internet Society.



















Newton                     Expires February 12, May 5, 2003                 [Page 31] 29]

----