view Side-By-Side changes

Network Working Group                                          A. Newton
Internet-Draft                                            VeriSign, Inc.
Expires: May December 5, 2003                                   November 04, 2002                                  June 06, 2003


 IRIS - The Internet Registry Information Service (IRIS)
                     draft-ietf-crisp-iris-core-01 Core Protocol
                     draft-ietf-crisp-iris-core-02

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.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May December 5, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002). (2003).  All Rights Reserved.

Abstract

   This document describes an application layer client-server protocol
   for a framework of representing the query and result operations of
   the information services of Internet registries.  Specified in XML,
   the protocol defines generic query and result operations and a
   mechanism for extending these operations for specific registry
   service needs.









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


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Use of XML . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2   General Concepts . . . . . . . . . . . . . . . . . . . . . .  3
   1.3   Framework Layers . . . . . . . . . . . . . . . . . . . . . .  4
   1.4   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.5   Other Documents  . . . . . . . . . . . . . . . . . . . . . .  5
   2.    Protocol Identification  . . . . . . . . . . . . . . . . . .  6
   3.    Exchange Description . . . . . . . . . . . . . . . . . . . .  7
   3.1   Request Format . . . . . . . . . . . . . . . . . . . . . . .  7
   3.2   Response Format  . . . . . . . . . . . . . . . . . . . . . .  7
   3.3   Extension Framework  . . . . . . . . . . . . . . . . . . .  9 . 10
   3.3.1 Derived Elements . . . . . . . . . . . . . . . . . . . . .  9 . 10
   3.3.2 Registry Type Identifier Requirements  . . . . . . . . . . . . . 10
   3.3.3 Entity Classes . . . . . . . . . . . . . . . . . . . . . . 10 . 11
   3.3.4 Names of Entities  . . . . . . . . . . . . . . . . . . . . 11 . 12
   3.3.5 References to Entities . . . . . . . . . . . . . . . . . . . 12
   3.3.6 <result> Derived Elements  . . . . . . . . . . . . . . . . 12
   3.3.6.1 <serviceIdentification> . 13
   3.4   Relay Bags . . . . . . . . . . . . . . . . 12
   3.3.6.2 <simpleEntity> . . . . . . . . . 14
   4.    Database Serialization . . . . . . . . . . . . . 13
   4.      Database Serialization . . . . . . 16
   5.    Formal XML Syntax  . . . . . . . . . . . . 14
   5.      Formal XML Syntax . . . . . . . . . 19
   6.    The IRIS URI . . . . . . . . . . . 16
   6.      Internationalization Considerations . . . . . . . . . . . 22
   7.      IANA Considerations . . 26
   6.1   URI Definition . . . . . . . . . . . . . . . . . 23
   8.      Security Considerations . . . . . . 26
   6.2   Transport Specific Schemes . . . . . . . . . . . 24
           References . . . . . . 27
   6.3   URI Resolution . . . . . . . . . . . . . . . . . . 25
           Author's Address . . . . . 27
   6.3.1 Registry Dependent Resolution  . . . . . . . . . . . . . . . 27
   6.3.2 Default Resolution . 26
   A.      Document Terminology . . . . . . . . . . . . . . . . . . . 27
   B.      Acknowledgements . 28
   6.3.3 Transport & Service Location . . . . . . . . . . . . . . . . 29
   6.4   IRIS URI Examples  . . . . 28
           Full Copyright Statement . . . . . . . . . . . . . . . . . 29




















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


1. Introduction

   The specification outlined in this document is based on the
   functional requirements described in CRISP [1].

1.1 Use of XML

   This document describes the specification for the Internet
   7.    Checklists . . . . . . . . . . . . . . . . . . . . . . . . . 31
   7.1   Registry
   Information Service (IRIS), an XML text protocol with the purpose of
   describing the query types and result types of various registry
   information services.  IRIS is specified using the Extensible Markup
   Language (XML) 1.0 as described in [5], XML Schema notation as
   described in [7] and [8], and XML Namespaces as described in [6].

1.2 General Concepts

   Each type of Internet registry, such as address, routing, and domain,
   are identified by a registry identifier (ID).  This registry
   identifier is a URI, more specifically a URN, used within the XML
   instances to identify the XML schema formally describing the set of
   queries, results, and entity classes allowed within that type of
   registry.

   A registry information server may handle queries and serve results
   for multiple registry types.  Each registry type that a particular
   registry operator serves is a registry service instance.

   IRIS Definition Checklist  . . . . . . . . . . . . . . . 31
   7.2   Transport Mapping Checklist  . . . . . . . . . . . . . . . . 31
   8.    Internationalization Considerations  . . . . . . . . . . . . 32
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 33
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 34
         References . . . . . . . . . . . . . . . . . . . . . . . . . 35
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 37
   A.    NAPSTR and the XML schema formally describing IRIS do not specify any
   registry, registry identifier, or knowledge of a particular service
   instance or set Uses . . . . . . . . . . . . . . . . . . . . 38
   A.1   An Examples of instances. NAPSTR with IRIS is a specification  . . . . . . . . . . . . . . 38
   A.2   Using NAPSTR for a
   framework with which these registries can be defined, used, Cohabitation  . . . . . . . . . . . . . . . 39
   B.    Document Terminology . . . . . . . . . . . . . . . . . . . . 41
   C.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
         Intellectual Property and in
   some cases interoperate. Copyright Statements . . . . . . . 43







Newton                  Expires December 5, 2003                [Page 2]

Internet-Draft                 iris-core                       June 2003


1. Introduction

   The framework merely specifies specification outlined in this document is based on the elements
   functional requirements described in CRISP [1].

1.1 Use of XML

   This document describes the specification for registry identification and the elements which must be used to
   derive queries Internet Registry
   Information Service (IRIS), an XML text protocol with the purpose of
   describing the query types and results.

   This framework allows a result types of various registry type to define its own structure for
   naming, entities, queries, etc.  through
   information services.  IRIS is specified using the use of Extensible Markup
   Language (XML) 1.0 as described in [5], XML namespaces Schema notation as
   described in [7] and [8], and XML schemas (hence, a Namespaces as described in [6].

1.2 General Concepts

   Each kind of Internet 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. type.  The framework does define certain structures that can be common to
   all registry types, such as references to entities, search
   continuations, entity classes, and more.  A
   identifier for 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 is 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 URI, more specifically a search continuation allows for distributed
   searches.  Both referrals may span differing registry types and
   instances.  No assumptions or specifications are made about roots,
   bases, or meshes of entities.

1.3 Framework Layers

   The IRIS framework can conceptually be thought of as having three
   layers.

                            ----------------------------
         Registry-Specific  |domain | address | routing|
                            ----------------------------
           Common-Registry  |          IRIS            |
                            ----------------------------
     Application-Transport  |          beep            |
                            ----------------------------

   The differing layers have URN,
   used within the following responsibilities:

      Registry-Specific :: Defines XML instances to identify the XML schema formally
   describing the set of queries, results, and entity classes
      of a specific allowed
   within that type of registry.  Each specific

   The structure of these URN's makes no assumptions or restrictions on
   the type of registries they identify.  Therefore, IRIS may support
   multiple registry types of disparate or similar nature; it is
      identified by only a URN.

      Common-Registry :: Defines base operations and semantics common to
      all
   matter of definition.  For instance, a single registry types such as referrals, entity references, etc.  It
      also defines the syntaxes type may be
   defined for talking about specific domain name registries while multiple registry types (using may
   be defined for the various IP address registries.

   A registry ID's).

      Application-Transport :: Defines the mechanisms for
      authentication, message passing, connection information server may handle queries 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: serve results
   for multiple registry identifier (ID) - The identifier used to specify a
      particular type of registry. types.  Each registry type - A registry serving that a specific function, such as particular
   registry operator serves is a
      domain registry service instance.

   IRIS and the XML schema formally describing IRIS do not specify any
   registry, registry identifier, or an address registry.  Each type knowledge of registry a particular service
   instance or set of instances.  IRIS is
      assigned 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 identifier. identification and the elements which must be used to
   derive queries and results.

   This framework allows a registry schema - The definition type to define its own structure for
   naming, entities, queries, etc.  through the use of XML namespaces
   and XML schemas (hence, a registry type specifying 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



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


      the queries, results, and entity classes.                       June 2003


   all registry types, such as references to entities, search
   continuations, entity class - classes, and more.  A group of entities with a common registry type may declare
   its own definitions for all of these, or common
      set it may mix its derived
   definitions with the base definitions.

   IRIS defines two types of characteristics. referrals, an entity name - The identifier used to refer to reference and a single entity
      within an search
   continuation.  An entity class.

      entity URI - A formal pointer to reference indicates specific knowledge about
   an entity.  This URI contains individual entity, and a search continuation allows for
   distributed searches.  Both referrals may span differing registry ID, entity class, and entity name.

   The terms "derivative", "derive",
   types and "derivation" instances.  No assumptions or specifications are used with made about
   roots, bases, or meshes of entities.

1.3 Framework Layers

   The IRIS framework can conceptually be thought of as having three
   layers.

                            ----------------------------
         Registry-Specific  |domain | address | routing|
                            ----------------------------
           Common-Registry  |          IRIS            |
                            ----------------------------
     Application-Transport  |          beep            |
                            ----------------------------

   The differing layers have the
   same meaning for deriving one following responsibilities:

      Registry-Specific :: Defines queries, results, and entity classes
      of a specific type of element from another 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
   specified in XML_SS [8].

1.5 Other Documents

   While this document describes referrals, entity references, etc.  It
      also defines the structures at syntaxes for talking about specific registry
      types.

      Application-Transport :: Defines the core mechanisms for
      authentication, message passing, connection and session
      management, etc.  It also defines the URI syntax specific to the
      application-transport mechanism.  However, because of IRIS,
   other aspects the
      separation of IRIS are described in these related documents: iris-
   beep [2], iris-dreg [3], the layers, other transports can and iris-areg [4]. have been
      defined ( iris-lwz [18] ).


1.4 Definitions

   For clarity, the following definitions are supplied:




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


2. Protocol Identification

   The root element                       June 2003


   o  registry type - A registry serving a specific function, such as a
      domain registry or an address registry.  Each type of all request registry is
      assigned a URN.

   o  registry schema - The definition for a registry type specifying
      the queries, results, and entity classes.

   o  authority - A reference to the server or set of server containing
      information.

   o  entity class - A group of entities with a common type or common
      set of characteristics.

   o  entity name - The identifier used to refer to a single entity
      within an entity class.

   o  entity reference - A pointer to an entity composed of an
      authority, a registry type, an entity class, and an entity name.
      One type of entity reference is the IRIS URI (defined in Section 6
      ).

   The terms "derivative", "derive", and "derivation" are used with the
   same meaning for deriving one type of element from another as
   specified in XML_SS [8].

1.5 Other Documents

   This document describes the structure at the core of IRIS.  The
   following documents describe the other aspects of IRIS relevant to
   CRISP [1]: iris-beep [2], and iris-dreg [3].

   The following documents describe aspects of IRIS that are not
   directly relevant to CRISP but demonstrate the flexibility and
   extensibility of IRIS: iris-areg [4], iris-lwz [18], and iris-credreg
   [19].
















Newton                  Expires December 5, 2003                [Page 5]

Internet-Draft                 iris-core                       June 2003


2. Protocol Identification

   The root element of all request XML instances MUST be <request>.  The
   root element of all response XML instances MUST be <response>.  These
   elements identifie identify the start of the IRIS elements, the XML namespace
   used as the identifier for IRIS, and the location of the schema.
   These elements and the associated closing tag MUST be applied to all
   requests and responses sent by both clients and servers.

   An abstracted example:

   <request xmlns="urn:ietf:params:xml:ns:iris1"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd">
   </request>

                                Figure 2

   The use of the schema location URI in the <xsi:schemaLocation>
   element is OPTIONAL with respect to its use by this specification,
   and IRIS implementations MAY resolve it to retrieve the schema or
   they MAY use a locally cached version of the schema.  The presence of
   this URI is mandatory according to [8].  The URI MUST be a valid URI,
   and SHOULD resolve if the appropriate network resources are
   available.

   Versioning of the IRIS protocol is the responsibility of the
   application-transport layer but MUST be associated with the XML
   namespace [6] URI representing IRIS.  A change in this URI indicates
   a change of the underlying schema and therefore a new version of the
   protocol.




















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


3. Exchange Description

   This section describes the request and response exchanges of the
   protocol.  The descriptions contained within this section refer to
   XML elements and attributes and their relation to the exchange of
   data within the protocol.  These descriptions also contain
   specifications outside the scope of the formal XML syntax.
   Therefore, this section will use terms defined by RFC 2119 [15] to
   describe the specification outside the scope of the formal XML
   syntax.  While reading this section, please reference Section 5 for
   needed details on the formal XML syntax.

3.1 Request Format

   A <request> element contains <searchSet> elements.  These <searchSet>
   elements enables a client to query a particular registry identified
   by its registry ID. type using
   the URN identifying the registy type.  This can be found in one of
   it's two children: <lookupEntity> and <query>.

   The children of the <lookupEntity> element contains describes the <entityName>
   and <entityClass> lookup of an entity in a
   specific registry.  This element and has a 'registryID' three attributes:
   'registryType', 'entityClass', and 'entityName'.  The 'registryType'
   attribute containing contains the registry identifier for the registry type in
   which the lookup operation is to take place.  The <entityClass> element 'entityClass'
   attribute contains the token identifying the index for which the
   lookup operation is to take place, and the <entityName> element 'entityName' attribute
   contains the name of the entity to lookup.

   The <query> element is abstract and may not legally appear in an XML
   instance.  It provides the base type to be used by registry schemas
   to define derived query types.  This derivation mechanism is
   described in Section 3.3.

3.2 Response Format

   The <response> element contains <resultSet> elements.  These
   <resultSet> elements are responses to a

   Each <searchSet> request.  The may also contain a <bag> element.  When this element
   appears as a child of <searchSet>, it MUST NOT contain the 'id'
   attribute.  For a description of the <bag> element, see Section 3.4.

3.2 Response Format

   The <response> element contains <resultSet> elements.  These
   <resultSet> elements are responses to a <searchSet> request.  The
   contents of this element contain an <answer> element, an optional
   <additional> element, an optional <bags> element, and error elements
   if applicable.

   The children of the <answer> element are of the following types:

   o  <result> is an abstract element and may not be legally placed in



Newton                  Expires December 5, 2003                [Page 7]

Internet-Draft                 iris-core                       June 2003


      an XML instance.  It provides the base type to be used by registry
      schemas to define derived result types.  This derivation mechanism
      is described in Section 3.3.

   o  The content of <entityURI>  <entity> is an element specifying an entity reference.  It has the
      following attributes to refer to the entity: 'authority',
      'registryType', 'entityClass', and 'entityName'.  It also may have
      a URI. <displayName> child element.  This child element notifies the
      client of specifies a
      human-friendly name (and appropriate language via its 'language'
      attribute) so the clients may present this entity reference to an entity. a
      user in a friendlier fashion.  The URI SHOULD be <entity> element may also have
      a 'bagRef' attribute.  If present, this attribute must contain an IRIS



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


      URI.  Resolution
      XML identifier to a <bag> element in the <bags> section of the URI is OPTIONAL by
      result set.  For a description of the client. 'bagRef' attribute, see
      Section 3.4.

   o  The <searchContinuation> element children contains an <authority>
      element and a <searchSet> <query> element.  The <authority> element indicates
      where the search continuation should be directed, and the <query>
      element is the query to be conducted.  The <searchContinuation>
      element may also contain a 'bagRef' attribute, and has the same
      meaning and purpose as specified with the <entity> element.  For a
      description of the 'bagRef' attribute, see Section 3.4.  The
      <searchContinuation> element may also have the attributes
      'authority', 'registryType', 'entityClass', and 'entityName'.
      These attributes are provided to give the search continuation
      context, especially for the purposes of database serialization
      (Section 4).

   When following entity references and search continuations, clients
   SHOULD only follow an <entityURI> <entity> or <searchContinuation> response once.
   Failure to do so may result in the client process getting stuck in a
   never-ending query loop commonly known as a referral loop.

   The <additional> element only contains <result> elements, as
   described above.

   The following elements representing error conditions may be returned:

   o  <insufficientResources> - the corresponding query requires
      resources unobtainable by the server.

   o  <invalidName> -  This element is provided to allow a name given in server to
   indicate to a client results that were not specifically queried but
   are related to the queried results, thus allowing the client the
   ability to properly display this distinction to a user.  The
   <additional> element use is optional.

   The <bags> element is optional.  It contains <bag> elements, and the
   contents of each <bag> element is unspecified by IRIS.  Each <bag>
   element has an 'id' attribute, which is referenced by the 'bagRef'
   attribute of entity references (<entity>) and search continuations
   (<searchContinuation>).  See Section 3.4.

   The following elements, representing error conditions, may be



Newton                  Expires December 5, 2003                [Page 8]

Internet-Draft                 iris-core                       June 2003


   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

   o  <bagUnrecognized> - the contents of a bag were unrecongnized.  See
      Section 3.4.

   o  <bagUnacceptable> - the contents of a bag were not and never will
      be acceptable.  See Section 3.4.

   o  <bagRefused> - the same as
      denying access to all <resultSet> responses because contents of failed
      authentication. a bag were not acceptable at this
      time.  See Section 3.4.

   o  A derivative of <genericCode>, as described in Section 3.3.

   The <resultSet> section is divided up into the <answer> and
   <additional> sections in order to allow easier processing and
   navigation of the results by a client.  Servers MUST return the
   direct answers to queries in the <answer> element, and MAY return
   results in the <additional> element for which a reference has been
   made to in the <answer> element.  Results in the <additional> element
   MUST have been referenced in the <answer> either as direct children
   of the <answer> element or as a deeper descendant of the <answer>
   element.

   This serves two purposes.  First, it may eliminate a requery by the



Newton                     Expires May 5, 2003                  [Page 8]

Internet-Draft                  iris-core                  November 2002
   client for references contained in the <answer> element.  Second, it
   distinguishes between results that are a direct result of a query and
   those that would have been returned had the client followed the
   appropriate referrals, thus giving clients a hint as to how to
   process or display the return returned results.  For instance, clients
   constructing complex displays using tree navigation widgets will know



Newton                  Expires December 5, 2003                [Page 9]

Internet-Draft                 iris-core                       June 2003


   that results in the <answer> element should all be directly beneath
   the root node of the tree, while results in the <additional> element
   are to be leaf nodes of those produced from the <answer> element.

3.3 Extension Framework

   Because the IRIS schema defines only one query type, no registry
   structure, and only two stand-alone result types, it is of limited
   use by itself.  Extension of IRIS is accomplished through the use a
   base IRIS schema, as defined in XML_SD [7] and XML_SS [8], and
   extension of it by schemas constructed on top of IRIS.

3.3.1 Derived Elements

   The XML Schema definition of IRIS requires schemas of registry types
   to derive element types from base types in the IRIS definition.  The
   registry schemas MUST derive elements for definition of typed queries
   and results.

   While the IRIS schema definition does not prohibit the derivation of
   any elements, registry schemas SHOULD restrict the derivations to the
   following types:

   o  <query> - as defined this element contains no content and has no
      valid attributes.  It is abstract and therefore only derivatives
      of it appear in an XML instances.  Registry schemas derive from this
      element to define the queries allowed.

   o  <result> - as defined this element contains no content and has one
      four valid attribute, "thisEntityURI". attributes: 'authority', 'registryType', 'entityClass'
      and 'entityName'.  It is abstract and therefore only derivatives
      of it appear in an XML instances.  Registry schemas derive from this
      element to define results that may be returned from a query.

   o  <genericCode> - as defined, this element is an instance of
      <codeType>.  It contains the optional elements <explanation> and
      <language> to further describe the nature of the error.

   o  <entityClass>  <seeAlso> - as defined this contains one or more <entity> elements.  This element represents the identifier
      for
      indicates one or more references to entities that have indirect
      association with a parent element representing an entity class. entity.
      Registry schemas SHOULD MAY derive from this element or MAY use it
      directly.


3.3.2 Registry Type Identifier Requirements

   The identifier for a registry type and the XML namespace identifier



Newton                  Expires December 5, 2003               [Page 10]

Internet-Draft                 iris-core                       June 2003


   used by the XML Schema describing the registry MUST be the same.
   These identifiers MUST be restricted to any valid URN [11].

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

   When possible, registry identifiers SHOULD be URN's defined by
   XML_URN [16].  Because these URN's represent namespace identifiers
   which are to be used in XML documents for the purposes of XML
   namespaces as specified by XML_NS [6], they MUST be of the class "ns"
   as defined in XML_URN [16].

   Case sensitivity of registry ID's is dependent on the namespace
   definition of the URN itself.  Registry ID's conforming to XML_URN
   [16] are case insensitive.

   When registry identifiers are URN's defined by XML_URN [16] and the
   class component is "ns", they MAY be abbreviated to the part
   following the class component and its separator of the URN.  For
   example, the full URN "urn:ietf:params:xml:ns:dreg1" may be
   abbreviated to "dreg1", but the full URN "urn:otherOrg:ns:myreg1"
   cannot be abbreviated.

   This abbreviation MUST NOT be used inside of XML instances in use
   with IRIS where XML Schema [7] specifies the use of a URI for schema
   identification or where XML_NS [6] specifies the use of a URI for XML
   namespace identification.

3.3.3 Entity Classes

   Entity classes are provided in IRIS to help avoid collisions with
   entity names with in any given registry type.  Their specification in
   queries also allows server implementations to quickly narrow search
   or lookup scopes to a single index.

   For instance, the entity name "10.0.1.0" would refer to separate
   entities in the "name-server" and "network" classes.  The entity
   "10.0.1.0" in the "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.0" in the "network" class
   may refer to the network 10.0.1/24.

   IRIS defines two default entity classes of "named-query" and
   "service-definition" which MAY NOT be redefined.  These entity
   classes MUST be valid in all registry types.

   The "named-query" class is for the naming of canned queries by
   registries.  Therefore an entity lookup of a canned query MAY result



Newton                  Expires December 5, 2003               [Page 11]

Internet-Draft                 iris-core                       June 2003


   in a search continuation on the same registry or a set of predefined
   results.  When used in URI's, this is a type of boot-strapping
   procedure.  Therefore, the resolution of "iris:com/dreg1/named-query/
   registrars" may result in the list of registrars currently
   registering domains.  The set of named queries are not specified by
   IRIS.

   The "service-definition" class is reserved for entities specific to a
   particular service instance.  It MUST contain an entity named "id"
   (see Section 3.3.4 which yields a result of <serviceIdentification>
   (see Section 3.3.6.1.  This entity class MAY contain other locally
   defined entities as well.

   The names of entity classes in a registry schema are of type token
   defined by XML_SD [7].  Their use SHOULD be transcribable.  Their
   case sensitivity MUST be defined by the definition of the registry
   type.  In general, they SHOULD be case insensitive.

3.3.4 Names of Entities

   The names of entities in a registry schema are of type token defined
   by XML_SD [7].  Their use SHOULD be transcribable.

   Names of entities SHOULD be unique within an instance of any
   particular entity class within a registry.  Two entities SHOULD NOT
   have the same name, but a single entity MAY be known by multiple
   names.  In situations where a single name may result in two entities,
   the registry schema SHOULD make allowances by defining result types
   that contain entity references to both entities (i.e.  "foo.com" can
   refer to both the domain foo.com and the host foo.com).  However,
   this type of conflict SHOULD generally be avoided by the proper use
   of entity classes.

   When specifying elements that represent entities, registry schemas
   must attach the attributes 'authority', 'registryType',
   'entityClass', and 'entityName'.  This aids clients in understanding
   which parts of a result set represent an entity.

   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 <entity> allows references to entities in result sets,



Newton                  Expires December 5, 2003               [Page 12]

Internet-Draft                 iris-core                       June 2003


   either as a direct child of <resultSet> or within a more complex
   structure that derives from <result>.  Registry schemas MUST NOT
   derive elements from this element so that clients will have a better
   understanding of what is and what isn't an entity reference.  This is
   especially useful to clients when dealing with XML conversion
   technologies such as XPath.

   The <entity> element can have a child element of <displayName> with
   an optional 'language' attribute.  These are provided so that servers
   may provide to clients a more human friendly meaning to the entity
   reference.  This is often useful to users navigating referral
   structures.

3.3.6 <result> Derived Elements

   The base IRIS framework does contain two elements directly derived
   from the <result> element for use by any registry type.

3.3.6.1 <serviceIdentification>

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

   o  <authorities> - This element contains one or more <authority>
      elements.  Each <authority> element contains a URI authority
      component for which the server has results.  While a server MAY
      only return a partial list of its authority areas depending on
      operator policy, it MUST return the authority for which the client
      has requested.

   o  <eMail> - This optional element contains an email address of the
      operator of the service instance.

   o  <phone> - This optional element contains the phone number of the
      operator of the service instance.

   o  <limits> - This optional element describes the limits of service a
      client will experience when querying this server.

   o  <seeAlso> - See Section 3.3.1 for its definition.

   The contents of the <limits> element are as follows:

   o  <accessLevel> -  This element is required and indicates to the
      client at which access level the described limits are active.  To
      do this, the element has two required boolean attributes:
      'atCurrentLevel' and 'atAnonymousLevel'.  If the limits described



Newton                  Expires December 5, 2003               [Page 13]

Internet-Draft                 iris-core                       June 2003


      by siblings of this element apply when a user is authenticated at
      the current access level used to conduct this query, then the
      'atCurrentLevel' attribute should be true.  If the limits
      described by siblings of this element apply when a user has given
      no authentication information or is considered to be anonymous,
      then the 'atAnonymousLevel' attribute should be true.

   o  <totalQueries> - This element describes the total number of
      queries that the server will accept at the indicated access level.
      The children of this element indicate this number per a unit of
      time.  The children are <perSecond>, <perMinute>, <perHour>, and
      <perDay>.  Each child MUST only appear once as a child of
      <totalQueries>, but more than one child MAY be present.  For
      example, a server could indicate that it will accept 15 queries a
      minute but only 60 queries a day.

   o  <totalResults> - This element describes the total number of
      results that the server will send to a client at the indicated
      access level.  The children of this element indicate this number
      per a unit of time in the same manner as <totalQueries>.


3.3.6.2 <simpleEntity>

   The <simpleEntity> element is provided so that service operators may
   make simple additions to other entities without the need for deriving
   entirely new registry types.  Its definition allows service operators
   to make it a referent from other entities (using, for instance, a
   <seeAlso> element).  The <simpleEntity> is meant to represent name
   and value pairs of strings, allowing each pair to be associated with
   a specific language qualifier.  Clients may easily display such
   information as a two-column table.  Uses needing binary data or
   richer data structures are out of scope for this element.  When such
   usage scenarios arise, it is likely that a client will need specific
   knowledge for handling such data thus calling into question the need
   for a new registry type.

3.4 Relay Bags

   IRIS employs the use of bags to allow a server to relay information
   to a referant server via the client.  The contents of the bags are
   not defined by IRIS, and the client MUST NOT make any assumptions
   about the contents of a bag when relaying it from one server to
   another.

   When a server returns a result set from a client, the <resultSet>
   element may contain a <bags> child element.  This child element
   contains one or more <bag> elements.  Each of these MUST contain an



Newton                  Expires December 5, 2003               [Page 14]

Internet-Draft                 iris-core                       June 2003


   'id' attribute containing the XML datatype ID.  Entity references and
   search continuations that need to specify a bag to be used when they
   are followed MUST have a 'bagRef' attribute containing the XML
   datatype IDREF.  See Section 3.2.  This allows the result set to only
   specify a bag once but allow each entity reference or search
   continuation to have a distinct bag as needed.

   When following an entity reference or search continuation that
   specifies the use of a bag, the client must include the refenced bag
   in the search set as the latter child of the <searchSet> element.
   See Section 3.1.

   See Section 3.2 for the list of errors a server may return to a
   client when a bag is received.





































Newton                  Expires December 5, 2003               [Page 15]

Internet-Draft                 iris-core                       June 2003


4. Database Serialization

   This section describes a method for serializing IRIS registry
   entities.  The descriptions contained within this section refer to
   XML elements and attributes and their relation to this serialization
   process.  These descriptions also contain specifications outside the
   scope of the formal XML syntax.  Therefore, this section will use
   terms defined by RFC 2119 [15] to describe the specification outside
   the scope of the formal XML syntax.  While reading this section,
   please reference Section 5 for needed details on the formal XML
   syntax.

   A database of IRIS entities can be serialized to file storage with
   XML [5] using the IRIS defined <serialization> element.  This element
   contains <result> element derivatives, <searchContinuation> elements,
   and <serializedNamedQuery> elements.

   Derivatives of the <result> element are entities.  Servers loading
   these entities MUST place the entity in the entity class specified by
   the elements 'registryType', 'entityClass', and 'entityName'
   attributes and any entity class which the entity may apply according
   to explicitly defined children of that element.  For instance, if a
   registry type has two entity classes of "foo" and "bar" and a
   <result> derivative has the attributes entityClass="foo" and
   entityName="one" and a child element <bar>two</bar>, the server is to
   enter that entity into the entity class "foo" as the name "one" and
   the entity class "bar" as the name "two".

   Servers loading entities as serialized derivatives of the <result>
   element MAY translate the authority attribute.  Servers will likely
   need to do this if the authority for the entity has changed.

   <searchContinuation> elements allow for the serialization of static
   referrals.  When this element appears as a child of the
   <serialization> element, it MUST have the 'authority',
   'registryType', 'entityClass', and 'entityName' attributes.

   <serializedNamedQuery> element allows for the specification of static
   results for a named query.  This element contains a <resultSet>
   element holding the results to be returned by the server if the named
   query is requested.  The server MUST place the named query in the
   "named-query" entity class.

   As mentioned above, there may be times when a server needs to
   translate the authority attribute of a loaded entity.  The
   <serializedEntity> element is provided for conditions where this must
   also be done for entity references.  During deserialization, servers
   MAY change the authority attribute of the <serializedEntity> element



Newton                  Expires December 5, 2003               [Page 16]

Internet-Draft                 iris-core                       June 2003


   to be an authority for which the server answers queries.  During
   serialization, servers and their related processes MUST use the
   <serializedEntity> element instead of the <entity> element for entity
   references in which the referent of the URI is an entity for which
   the server answers queries.  The authority attribute of the <entity>
   element SHOULD NOT be altered during serialization or
   deserialization.

   The following is an example of serialized IRIS.


   <iris:serialization
     xmlns:iris="urn:ietf:params:xml:ns:iris1"
     xmlns="urn:ietf:params:xml:ns:iris1"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >

     <serviceIdentification
       authority="com" registryType="dreg1"
       entityClass="service-definition"
       entityName="id" >
       <authorities>
         <authority> com </authority>
         <authority> net </authority>
       </authorities>
       <eMail>
         davidb@verisignlabs.com
       </eMail>
       <limits>
         <accessLevel atCurrentLevel="true"
           atAnonymousLevel="false" />
         <totalQueries>
           <perDay>15</perDay>
         </totalQueries>
         <totalResults>
           <perDay>100</perDay>
         </totalResults>
       </limits>
       <seeAlso>
         <entity
           authority="com" registryType="dreg1"
           entityClass="service-definition"
           entityName="notice">
           <displayName language="en">
             Legal Notice
           </displayName>
         </entity>
       </seeAlso>



Newton                  Expires December 5, 2003               [Page 17]

Internet-Draft                 iris-core                       June 2003


     </serviceIdentification>

     <simpleEntity
       authority="com" registryType="dreg1"
       entityClass="service-definition"
       entityName="notice" >
       <property name="legal" language="en">
         Please use the net wisely!  We are required to tell
         you this.
       </property>
     </simpleEntity>

   </iris:serialization>






































Newton                  Expires December 5, 2003               [Page 18]

Internet-Draft                 iris-core                       June 2003


5. Formal XML Syntax

   IRIS is specified in XML Schema notation.  The formal syntax
   presented here is a complete schema representation of IRIS suitable
   for automated validation of IRIS XML instances.


   <?xml version="1.0"?>
   <schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:iris="urn:ietf:params:xml:ns:iris1"
           targetNamespace="urn:ietf:params:xml:ns:iris1"
           elementFormDefault="qualified" >

     <annotation>
       <documentation>
         Internet Registry Information Service (IRIS) Schema v1
       </documentation>
     </annotation>

     <element name="request">
       <complexType>
         <sequence>
           <element name="searchSet"
             type="iris:searchSetType"
             minOccurs="0" maxOccurs="unbounded" />
         </sequence>
       </complexType>
     </element>

     <element name="response">
       <complexType>
         <sequence>
           <element name="resultSet"
             type="iris:resultSetType"
             minOccurs="0" maxOccurs="unbounded" />
         </sequence>
       </complexType>
     </element>

     <complexType name="searchSetType" >
       <sequence>
         <choice>
           <element name="lookupEntity"
             type="iris:lookupEntityType" />
           <element ref="iris:query" />
         </choice>
         <element name="bag" type="iris:bagType"
           minOccurs="0" maxOccurs="1" />



Newton                  Expires December 5, 2003               [Page 19]

Internet-Draft                 iris-core                       June 2003


       </sequence>
     </complexType>

     <complexType name="queryType"/>

     <element name="query"
       type="iris:queryType"
       abstract="true" />

     <complexType name="lookupEntityType" >
       <attribute name="registryType"
         type="anyURI" use="required" />
       <attribute name="entityClass"
         type="token" use="required" />
       <attribute name="entityName"
         type="token" use="required" />
     </complexType>

     <complexType name="codeType">
       <sequence minOccurs="0" maxOccurs="1">
         <element name="explanation" type="string" />
         <element name="language" type="language" />
       </sequence>
     </complexType>

     <complexType name="entityType">
       <sequence>
         <element name="displayName"
           minOccurs="0" maxOccurs="1">
           <complexType>
             <simpleContent>
               <extension base="string">
                 <attribute name="language" use="required" type="language" />
               </extension>
             </simpleContent>
           </complexType>
         </element>
       </sequence>
       <attribute name="authority" use="required" type="token" />
       <attribute name="registryType" use="required" type="anyURI" />
       <attribute name="entityClass" use="required" type="token" />
       <attribute name="entityName" use="required" type="token" />
       <attribute name="bagRef" type="IDREF" />
     </complexType>

     <element name="entity"
       type="iris:entityType" />




Newton                  Expires December 5, 2003               [Page 20]

Internet-Draft                 iris-core                       June 2003


     <complexType name="seeAlsoType">
       <sequence>
         <element ref="iris:entity"
           minOccurs="1" maxOccurs="unbounded" />
       </sequence>
     </complexType>

     <element name="seeAlso" type="iris:seeAlsoType" />

     <complexType name="resultSetType" >
       <sequence>
         <element name="answer"
           minOccurs="1" maxOccurs="1">
           <complexType>
             <sequence>
               <element ref="iris:result"
                 minOccurs="0" maxOccurs="unbounded" />
               <element ref="iris:entity"
                 minOccurs="0" maxOccurs="unbounded" />
               <element ref="iris:searchContinuation"
                 minOccurs="0" maxOccurs="unbounded" />
             </sequence>
           </complexType>
         </element>
         <element name="additional"
           minOccurs="0" maxOccurs="1">
           <complexType>
             <sequence>
               <element ref="iris:result"
                 minOccurs="0" maxOccurs="unbounded" />
             </sequence>
           </complexType>
         </element>
         <element name="bags" type="iris:bagsType"
           minOccurs="0" maxOccurs="1" />
         <choice
           minOccurs="0" maxOccurs="1" >
           <element name="insufficientResources"
             type="iris:codeType" />
           <element name="invalidName"
             type="iris:codeType" />
           <element name="invalidSearch"
             type="iris:codeType" />
           <element name="limitExceeded"
             type="iris:codeType" />
           <element name="nameNotFound"
             type="iris:codeType" />
           <element name="permissionDenied"



Newton                  Expires December 5, 2003               [Page 21]

Internet-Draft                 iris-core                       June 2003


             type="iris:codeType" />
           <element name="bagUnrecognized"
             type="iris:codeType" />
           <element name="bagUnacceptable"
             type="iris:codeType" />
           <element name="bagRefused"
             type="iris:codeType" />
           <element ref="iris:genericCode"/>
         </choice>
       </sequence>
     </complexType>

     <complexType name="bagsType">
       <sequence>
         <element name="bag" type="iris:bagType"
           minOccurs="1" maxOccurs="unbounded" />
       </sequence>
     </complexType>

     <complexType name="bagType" mixed="true">
       <sequence>
         <any namespace="##other"
           minOccurs="0" maxOccurs="unbounded" />
       </sequence>
       <attribute name="id" type="ID"/>
     </complexType>

     <complexType name="resultType">
       <attribute name="authority" use="required" type="token" />
       <attribute name="registryType" use="required" type="anyURI" />
       <attribute name="entityClass" use="required" type="token" />
       <attribute name="entityName" use="required" type="token" />
     </complexType>

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

     <complexType name="searchContinuationType">
       <sequence>
         <element name="authority" type="token"
           minOccurs="1" maxOccurs="1" />
         <element ref="iris:query" />
       </sequence>
       <attribute name="authority" type="token" />
       <attribute name="registryType" type="anyURI" />
       <attribute name="entityClass" type="token" />
       <attribute name="entityName" type="token" />



Newton                  Expires December 5, 2003               [Page 22]

Internet-Draft                 iris-core                       June 2003


       <attribute name="bagRef" type="IDREF" />
     </complexType>

     <element name="searchContinuation"
       type="iris:searchContinuationType" />

     <element name="genericCode" type="iris:codeType"
       abstract="true" />

     <element name="serializedEntity"
       type="iris:entityType"
       substitutionGroup="iris:entity" />

     <complexType name="serializedNamedQueryType">
       <sequence>
         <element name="resultSet"
           type="iris:resultSetType" />
       </sequence>
       <attribute name="registryType" type="anyURI"
         use="required" />
       <attribute name="entityClass" type="token"
         fixed="named-query" />
       <attribute name="entityName" type="token"
         use="required" />
     </complexType>

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

     <complexType name="serviceIdentificationType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>
             <element name="authorities"
               minOccurs="1" maxOccurs="1">
               <complexType>
                 <sequence>
                   <element name="authority" type="token"
                     minOccurs="1" maxOccurs="unbounded" />



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


   o  <seeAlso> - contains one or more <entityURI> elements.  This
      element indicates one or more references to entities that have
      indirect association with a parent element representing an entity.
      Registry schemas MAY derive from this element or MAY use it
      directly.


3.3.2 Registry Identifier Requirements

   The identifier for a registry and the XML namespace identifier used
   by the XML Schema describing the registry MUST be the same.  These
   identifiers MUST be restricted to any valid URN [11].

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

   When possible, registry identifiers SHOULD be URN's defined by
   XML_URN [16].  Because these URN's represent namespace identifiers
   which are to be used                       June 2003


                 </sequence>
               </complexType>
             </element>
             <element name="eMail" type="string"
               minOccurs="0" maxOccurs="1" />
             <element name="phone" type="string"
               minOccurs="0" maxOccurs="1" />
             <element name="limits"
               minOccurs="0" maxOccurs="1">
               <complexType>
                 <sequence>
                   <element name="accessLevel"
                     minOccurs="1" maxOccurs="1">
                     <complexType>
                       <attribute name="atCurrentLevel"
                         type="boolean" use="required" />
                       <attribute name="atAnonymousLevel"
                         type="boolean" use="required" />
                     </complexType>
                   </element>
                   <element name="totalQueries"
                     minOccurs="0" maxOccurs="1" >
                     <complexType>
                       <group ref="iris:timeLimitsGroup"
                         minOccurs="1" maxOccurs="4" />
                     </complexType>
                   </element>
                   <element name="totalResults"
                     minOccurs="0" maxOccurs="1" >
                     <complexType>
                       <group ref="iris:timeLimitsGroup"
                         minOccurs="1" maxOccurs="4" />
                     </complexType>
                   </element>
                 </sequence>
               </complexType>
             </element>
             <element ref="iris:seeAlso"
               minOccurs="0" maxOccurs="1" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="serviceIdentification"
       type="iris:serviceIdentificationType"
       substitutionGroup="iris:result" />




Newton                  Expires December 5, 2003               [Page 24]

Internet-Draft                 iris-core                       June 2003


     <group name="timeLimitsGroup">
       <choice>
         <element name="perSecond" type="nonNegativeInteger" />
         <element name="perMinute" type="nonNegativeInteger" />
         <element name="perHour  " type="nonNegativeInteger" />
         <element name="perDay   " type="nonNegativeInteger" />
       </choice>
     </group>

     <complexType name="simpleEntityType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>
             <element name="property"
               minOccurs="1" maxOccurs="unbounded">
               <complexType>
                 <simpleContent>
                   <extension base="string">
                     <attribute name="name" type="string"
                       use="required" />
                     <attribute name="language" type="language"
                       use="required" />
                   </extension>
                 </simpleContent>
               </complexType>
             </element>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

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

   </schema>

                                Figure 4













Newton                  Expires December 5, 2003               [Page 25]

Internet-Draft                 iris-core                       June 2003


6. The IRIS URI

   The IRIS URI has a very rigid structure but is flexible in XML documents for the purposes of XML
   namespaces as specified by XML_NS [6], they MUST how it may
   be of the class "ns"
   as defined in XML_URN [16].

   Case sensitivity of registry ID's used.  Its structure is dependent on the namespace
   definition of rigid in that all IRIS URI's have the URN itself.  Registry ID's conforming same
   fields and all look similar to XML_URN
   [16] are case insensitive.

   When registry identifiers users.

   They are URN's defined by XML_URN [16] and the
   class component is "ns", flexible because they MAY be abbreviated allow for different methods 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
   employed to "dreg1", but the full URN "urn:otherOrg:ns:myreg1"
   cannot be abbreviated.

   This abbreviation MUST NOT be used inside of XML instances in use
   with IRIS where XML Schema [7] specifies find servers based on the use of a URI registry type and they allow
   for schema
   identification or where XML_NS [6] specifies the use of a multiple transports (with BEEP being the default).

6.1 URI for XML
   namespace identification.

3.3.3 Entity Classes

   Entity classes are provided in Definition

   An IRIS to help avoid collisions with
   entity names URI [10] has the following general syntax.

   iris:<authority>/<registry-urn>/<entity-class>/<entity-name>

   The full ABNF [20] with in any given registry type.  Their specification in
   queries also allows server implementations to quickly narrow search
   or lookup scopes to certain values included from RFC2396 [10] and
   RFC2732 [23] follows.


     iris-uri           = scheme + ":" authority "/" registry-urn [ "/"
                          entity-class "/" entity-name ]
     scheme             = "iris"
     authority          = with-app-svc | without-app-svc
     with-app-svc       = [ userinfo "@" ] hostname [ ";" app-svc ]
     without-app-svc    = [ userinfo "@" ] ( ( host ":" port ) | ipaddress )
                          [ ";" ]
     userinfo           = // as specified by RFC2396
     host               = hostname | ipaddress
     ipaddress          = IPv4Address | IPv6Address
     IPv4Address        = // as specified by RFC2396
     IPv6Address        = // as specified by RFC2732
     port               = // as specified by RFC2396
     hostname           = // as specified by RFC2396
     app-svc            = *(unreserved | escaped)
     registry-urn       = // as specified by IRIS
     entity-class       = *(unreserved | escaped)
     entity-name        = *(unreserved | escaped)
     unreserved         = // as specified by RFC2396
     escaped            = // as specified by RFC2396

   An IRIS URI MUST NOT be a single index.  A registry schema derives the
   list of relative URI.  In addition, valid URI's
   with this scheme MUST always contain a registry URN (namespace
   identifier), an entity classes from the <entityClass> element.

   For instance, the entity name "10.0.1.1" would refer to separate
   entities in the "name-server" class, and "network" classes.  The an 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 name.  In addition, the
   entity "10.0.1.1" in the "network" class
   may refer to the network 10.0.1/24.

   IRIS defines two default entity classes of "named-query" and
   "service-definition" which MAY NOT be redefined.  These entity
   classes name MUST be valid in all registry types.

   The "named-query" class is for the naming of canned queries by
   registries.  Therefore an entity lookup of a canned query MAY result
   in a search continuation on the same registry or a UTF-8 [21] character set of predefined
   results.
   encoded with "application/x-www-form-urlencoded" as specified by
   URL_ENC [22].




Newton                  Expires December 5, 2003               [Page 26]

Internet-Draft                 iris-core                       June 2003


   When used in URI's, this is a type of boot-strapping
   procedure.  Therefore, the resolution of "iris://com/dreg1/named-
   query/registrars" may result in the list of registrars currently
   registering domains.  The set of named queries entity-class and entity-name components are not specified by
   IRIS.

   The specified,
   the defaults "service-definition" class and "id" MUST be implied.  For
   example, "iris:com/dreg1" 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 be interpreted "iris:com/dreg1/
   service-definition/id".

   Definitions of <serviceIdentification>
   (see Section 3.3.6.1.  This entity class MAY contain other locally
   defined entities as well.

   The registry types SHOULD attempt to make the names of
   entity classes in a registry schema transcribable.  Despite the fact that URI's are of type token
   defined by XML_SD [7].  Their use SHOULD not
   friendly to all humans, the care should be taken in their definition
   to make them readable and transcribable.  Their
   case sensitivity MUST be defined by  One aspect of this is the definition
   use of dashes to separate meaningful words over the registry
   type. use of other
   styles such as camel back notation (e.g.  "service-definition"
   instead of "serviceDefinition").

   The optional app-svc component refers to an application service
   label.  See Section 6.3.3.  In general, they SHOULD be case insensitive.

3.3.4 Names all cases it is preceded by a
   semi-colon (';'), which indicates the use of Entities the default resolution
   rules (Section 6.3.2).

6.2 Transport Specific Schemes

   The names "iris" scheme name is not application transport specific.  The
   URI resolution process MAY determine the application transport.  An
   example of entities such a process is the default resolution (Section 6.3.2)
   process, which uses the steps outlined in Section 6.3.3 to determine
   the application transport.

   A mapping between an application transport and IRIS MAY define a registry schema are of type token defined
   by XML_SD [7].  Their
   scheme name signifying its use SHOULD be transcribable.

   Names with the semantics of entities the IRIS URI.

   The rules for determining which application transport to use are:

   o  If a transport specific scheme name is present, the application
      transport it signifies SHOULD be unique within an instance of any
   particular entity class within used if possible.

   o  If a registry.  Two entities SHOULD NOT
   have the same name, but client has a single entity preferred transport and the resolution process
      allows for its use, the client MAY be known by multiple
   names.  In situations where a single name may result in two entities, use that application transport.

   o  Otherwise, the registry schema SHOULD make allowances default application transport as specified by defining result types
   that contain entity references to both entities (i.e.  "foo.com"
      IRIS-BEEP [2] MUST be used.


6.3 URI Resolution

6.3.1 Registry Dependent Resolution

   The IRIS URI resolution process can
   refer to both the domain foo.com and the host foo.com).  However,
   this type of conflict SHOULD generally be avoided by dependent on the proper use
   of entity classes.

   When specifying elements that represent entities, registry schemas
   must attach type
   used in the attribute URI itself and keyed off of "thisEntityURI" with the datatype of
   anyURI as specified by XML_SD [7].  This aids clients registry URN that appears
   in
   understanding which parts it in the absense of a result set represent an entity.  The user override.  In other words, the way in



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


   URI value in                       June 2003


   which the XML instance SHOULD be an IRIS URI.

   The case sensitivity authority component of entity names the URI is processed is dependent on
   the entity class
   in which they reside.  The definition of a registry type MUST specify type's URN, unless the case sensitivity for entity names.  A registry type MAY define user is specific about 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
   process.

   The element <entityURI> allows references rules for determining which resolution process to entities in result sets,
   either as a direct child of <resultSet> or within a more complex
   structure that derives from <result>.  Registry schemas MUST NOT
   derive elements from this element so that clients will have use are:

   o  If the authority contains a better
   understanding of what is and what isn't an entity reference.  This is
   especially useful to clients when dealing semi-colon (';') with XML conversion
   technologies such as XPath.

   The <entityURI> element can have the two attributes "displayName" and
   "language".  These are provided so that servers may provide an application
      service label, see Section 6.1, then the default resolution
      process defined in Section 6.3.2 is to
   clients a more human friendly meaning be used.  The application
      service label to be used is that given after the entity reference.  This semi-colon.  If
      none is given, the registry type assigned application service
      label is often useful to user navigating referral structures.

3.3.6 <result> Derived Elements

   The base IRIS framework does contain two elements directly derived
   from be used.

   o  Otherwise, the <result> element for use resolution process specified by any the registry type.

3.3.6.1 <serviceIdentification>

   The <serviceIdentification> element type
      is provided used.  Every registry type MUST specify a resolution process
      for URI's, even if that specification only defines an application
      service label and reverts to allow IRIS clients the ability to reference IRIS service instances.  It contains default process.  In all cases,
      the
   following elements:

   o  <authorities> - This element contains one authority component of the URI MUST be compliant with RFC2396
      [10] and RFC2732 [23].


6.3.2 Default Resolution

   In the default resolution process, the authority component of an IRIS
   URI may only contain a domain name, a domain name accompanied by a
   port number, an IP address, or more <authority>
      elements.  Each <authority> element contains an IP address accompanied by a URI port
   number.  The authority component for which of the scheme indicates the server has results.  While
   or set of servers authoritatively responsible for a server MAY
      only return domain according
   to records in DNS (Section 6.3.3) if a partial list of its domain is specified or
   indicates the specific server to be queried if an IP address is
   specified.

   The rules for resolution are:

   o  If the authority areas depending on
      operator policy, it MUST return component is a domain name accompanied by a port
      number as specified by RFC2396, the domain name is converted to an
      IP address via an A or AAAA record to the DNS.

   o  If the authority component is a domain name by itself, the
      service/transport location (Section 6.3.3) process is used.  If
      this process produces no results, then the DNS is queried for which the client
      has requested.

   o  <eMail> - This optional element contains an email address of
      A or AAAA RRs corresponding to the
      operator domain name and the port number
      used is the well-known port of the service instance. transport used according to
      Section 6.2.

   o  <phone> - This optional element contains  If the phone number of authority component is an IP address, then the
      operator of DNS is not
      queried, and the service instance. IP address is used directly.  If the port number
      is present, it is used directly; otherwise, the port number used



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


   o  <seeAlso> - See                       June 2003


      is the well-known port of the transport used according to Section 3.3.1 for its definition.


3.3.6.2 <simpleEntity>
      6.2.

   The <simpleEntity> element is provided so that service operators may
   make simple additions use of an IPv6 address in the authority component MUST conform to other entities without
   RFC2732 [23].

6.3.3 Transport & Service Location

   The default resolution process uses the need for deriving
   entirely new registry types.  Its definition allows service operators profiled use of the NAPTR and
   SRV resource records as defined in NAPSTR [17] to make it determine both the
   location of a referent from other entities (using, set of servers for instance, a
   <seeAlso> element).  The <simpleEntity> is meant to represent name given service and value pairs the set of strings, allowing each pair to be associated with
   a specific language qualifier.  Clients
   possible transports that may easily display such
   information as a two-column table.  Uses needing binary data or
   richer data structures be used.  Any registry type not
   deferring to the default resolution process SHOULD use NAPSTR [17]
   for this purpose.

   NAPSTR [17] requires an application service label.  If this is not
   specified in the URI (or by the user in some fashion), then the
   application service label used is that assigned by the registry type.

   See Appendix A for example uses of NAPSTR.

6.4 IRIS URI Examples

   Here are out some examples of scope IRIS URI's and their meaning:

   o  iris:example.com/dreg/domain/example.com

      *  Finds a server authoritative for this element.  When such
   usage scenarios arise, it "example.com" according to the
         rules of the registry type "urn:ietf:params:xml:ns:dreg".

      *  The server is likely that asked for "example.com" in the "domain" index, or
         entity class, of the "dreg" registry.

   o  iris:example.com/dreg

      *  Finds a client will need specific
   knowledge server authoritative for handling such scenarios thus calling into question "example.com" according to the
   need
         rules of the registry type "urn:ietf:params:xml:ns:dreg".

      *  The server is asked for "id" in the "service-definition" index,
         or entity class, of the "dreg" registry.

   o  iris:com/dreg/domain/example.com

      *  Finds a new server authoritative for "com" according to the rules
         of the registry type. type "urn:ietf:params:xml:ns:dreg".

      *  The server is asked for "example.com" in the "domain" index, or
         entity class, of the "dreg" registry.



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


4. Database Serialization

   This section describes a method for serializing IRIS registry
   entities.  The descriptions contained within this section refer to
   XML elements and attributes and their relation to this serialization
   process.  These descriptions also contain specifications outside the
   scope of the formal XML syntax.  Therefore, this section will use
   terms defined by RFC 2119 [15] to describe                       June 2003


   o  iris:10.0.1.1:44/dreg/domain/example.com

      *  Assuming that the specification outside registry type "urn:ietf:params:xml:ns:dreg"
         uses the scope of default resolution process when it encounters IP
         addresses, the formal XML syntax.  While reading this section,
   please reference Section 5 for needed details server at 10.0.1.1 on the formal XML
   syntax.

   A database of IRIS entities can be serialized to file storage with
   XML [5] port 44 is queried using the IRIS defined <serialization> element.  This element
   contains <result> element derivatives, <searchContinuation> elements,
         BEEP.  The assumption here is that "dreg" means "domain
         registry" and <serializedNamedQuery> elements

   Derivatives is therefore not terribly concerned about
         definitions other than finding authoritative servers for domain
         names.

      *  The server is asked for "example.com" in the "domain" index, or
         entity class, of the <result> element are entities.  Servers loading
   these entities MUST place "dreg" registry.

   o  iris-lwz:10.0.1.1:44/dreg/domain/example.com

      *  Assuming that the entity in registry type "urn:ietf:params:xml:ns:dreg"
         uses the entity class specified by default resolution process when it encounters IP
         addresses, the elements 'thisEntityURI' attribute and any entity class which server at 10.0.1.1 on port 44 is queried using a
         lightweight transport.

      *  The server is asked for "example.com" in the "domain" index, or
         entity may apply class, of the "dreg" registry.

   o  iris-beep:com/dreg/domain/example.com

      *  Finds a server authoritative for "com" according to explicitly defined children the rules
         of that
   element.  For instance, if a the registry type has two "urn:ietf:params:xml:ns:dreg".

      *  Uses the BEEP application transport.

      *  The server is asked for "example.com" in the "domain" index, or
         entity classes class, of
   "foo" and "bar" and a <result> derivative has the attribute
   thisEntityURI="iris://example.authority/example.registry/foo/one" and "dreg" registry.

   o  iris-beep:example.com;dreg/dreg/domain/example.com

      *  Finds a child element <bar>two</bar>, server authoritative for "com" according to the default
         resolution process using "dreg" as the application service
         label.

      *  Uses the BEEP application transport.

      *  The server is enter that entity into asked for "example.com" in the "domain" index, or
         entity class "foo" as named "one" and class, of the entity class "bar" as
   named "two".

   Servers loading entities as serialized derivatives "dreg" registry.








Newton                  Expires December 5, 2003               [Page 30]

Internet-Draft                 iris-core                       June 2003


7. Checklists

7.1 Registry Definition Checklist

   Specifications of registry types MUST include the <result>
   element MAY translate following explicit
   definitions:

   o  Formal XML syntax deriving from the authority component IRIS XML.

   o  An identifying registry URN.

   o  URI resolution scheme - A definition of the URI specified in process of resolving
      the 'thisEntityURI' attribute.  Server will likely need authority of an IRIS URI or a declaration to do this if use the default
      authority resolution scheme in Section 6.3.2.

   o  An application service label for the entity has changed.

   <searchContinuation> elements allow for the serialization of static
   referrals.  When compliance with NAPSTR [17].  See
      Section 6.3.3.  Note, this element appears as is a child of the
   <serialization> element, it MUST have the "thisEntityURI" attribute.

   <serializedNamedQuery> element allows for different IANA registry than the specification of static
   results for a named query.  This element contains a <resultSet>
   element holding
      registry type URN IANA registry, however, using the results to be returned by abbreviated
      (Section 3.3.2) form of the server if registry URN as the named
   query application
      service label is requested.  The server MUST place good practice.

   o  A list of well-known entity classes.

   o  A statement regarding the named query in case sensitivity of the
   "named-query" names in each
      entity class.

   As mentioned above, there may be times when a server needs to
   translate the authority section


7.2 Transport Mapping Checklist

   Specifications of an IRIS transport mappings MUST include the following
   explicit definitions:

   o  A URI when loading entities.
   The <serializedEntityURI> element is provided scheme name specific to the transport.

   o  An application protocol label for conditions where compliance with NAPSTR [17].
      See Section 6.3.3.  Note, this must also be done for entity references.  During
   deserialization, servers MAY change is a different IANA registry than
      the authority component scheme name IANA registry, however, there is nothing stopping
      them from being the same string of an characters.













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


8. Internationalization Considerations

   IRIS URI contained within the <serializedEntityURI> element to be an
   authority for is represented in XML, which provides native support for
   encoding information using the server answers queries.  During
   serialization, servers double-byte Unicode character set and their related processes MUST
   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 the
   <serializedEntityURI> element instead of the <entityURI> element for
   entity references an "encoding" attribute in which the referent of the URI is an entity for
   which the server answers queries. <?xml?>
   processing instruction.  The authority component contained
   within an IRIS URI complete list of character set encoding
   identifiers is maintained by IANA and is described in  [25] and [12].

   The application-transport layer MUST define a common set of character
   set encodings to be understood by both client and server.

   Localization of internationalized strings may require additional
   information by the <entityURI> element client.  Entity definitions SHOULD NOT be altered
   during serialization or deserialization.

   The following is an example of serialized IRIS.


   <iris:serialization
     xmlns:iris="urn:ietf:params:xml:ns:iris1"
     xmlns="urn:ietf:params:xml:ns:iris1"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >

     <serviceIdentification
       thisEntityURI="iris://com/dreg1/service-definition/id" >
       <authorities>
         <authority> com </authority>
         <authority> net </authority>
       </authorities>
       <eMail>
         davidb@verisignlabs.com
       </eMail>
       <seeAlso>
         <entityURI>
           iris://com/dreg1/service-definition/notice
         </entityURI>
       </seeAlso>
     </serviceIdentification>

     <simpleEntity
       thisEntityURI="iris://com/dreg1/service-definition/notice">
       <property name="legal" language="en">
         Please use the net wisely!  We are required
   "language" type defined by XML_SD [7] to tell
         you this.
       </property>
     </simpleEntity>

   </iris:serialization> aid clients in the
   localization process.  See Section 3.3.6.2 as an example.

































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


5. Formal XML Syntax

   IRIS is specified in                       June 2003


9. IANA Considerations

   XML Schema notation.  The formal syntax
   presented here is schemas require a complete schema representation of IRIS suitable URI for automated validation unique identification.  Schemas MUST be
   registered to ensure URI uniqueness, but the IETF does not currently
   have a recommended repository for the registration of IRIS XML instances.


   <?xml version="1.0"?>
   <schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:iris="urn:ietf:params:xml:ns:iris1"
           targetNamespace="urn:ietf:params:xml:ns:iris1"
           elementFormDefault="qualified" >

     <annotation>
       <documentation>
         Internet Registry Information Service (IRIS) Schema v1
       </documentation>
     </annotation>

     <element name="request">
       <complexType>
         <sequence>
           <element name="searchSet"
             type="iris:searchSetType"
             minOccurs="0" maxOccurs="unbounded" />
         </sequence>
       </complexType>
     </element>

     <element name="response">
       <complexType>
         <sequence>
           <element name="resultSet"
             type="iris:resultSetType"
             minOccurs="0" maxOccurs="unbounded" />
         </sequence>
       </complexType>
     </element>

     <complexType name="searchSetType" >
       <choice>
         <element name="lookupEntity"
           type="iris:lookupEntityType" />
         <element ref="iris:query" />
       </choice>
     </complexType>

     <complexType name="queryType"/> schemas.
   This document uses URNs to describe XML namespaces and XML schemas.
   IANA SHOULD maintain a registry of XML namespace and schema URI
   assignments.  Per policies described in [13], URI assignment requests
   SHOULD be reviewed by a designated expert, and values SHOULD be
   assigned only as a result of standards action taken by the IESG.

   This document makes use of a proposed XML namespace and schema
   registry specified in XML_URN [16].  Accordingly, the following URN
   will need to be registered with IANA:

      urn:ietf:params:xml:ns:iris1



































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


     <element name="query"
       type="iris:queryType"
       abstract="true" />

     <simpleType name="entityClassType">
       <restriction base="token">
       </restriction>
     </simpleType>

     <element name="entityClass"
       type="iris:entityClassType" />

     <simpleType name="baseentityClassType">
       <restriction base="iris:entityClassType">
         <enumeration value="named-query" />
         <enumeration value="service-definition" />
       </restriction>
     </simpleType>

     <element name="baseentityClass"
       type="iris:baseentityClassType"
       substitutionGroup="iris:entityClass" />

     <complexType name="lookupEntityType" >
       <sequence>
         <element name="entityName" type="token" />
         <element ref="iris:entityClass" />
       </sequence>
       <attribute name="registryID"
         type="anyURI" use="required" />
     </complexType>

     <complexType name="codeType">
       <sequence minOccurs="0" maxOccurs="1">
         <element name="explanation" type="string" />
         <element name="language" type="language" />
       </sequence>
     </complexType>

     <complexType name="entityURIType">
       <simpleContent>
         <extension base="anyURI">
           <attribute name="displayName" type="string" />
           <attribute name="language" type="language" />
         </extension>
       </simpleContent>
     </complexType>




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


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

     <complexType name="seeAlsoType">
       <sequence>
         <element ref="iris:entityURI"
           minOccurs="1" maxOccurs="unbounded" />
       </sequence>
     </complexType>

     <element name="seeAlso" type="iris:seeAlsoType" />

     <complexType name="resultSetType" >
       <sequence>
         <element name="answer"
           minOccurs="1" maxOccurs="1">
           <complexType>
             <sequence>
               <element ref="iris:result"
                 minOccurs="0" maxOccurs="unbounded" />
               <element ref="iris:entityURI"
                 minOccurs="0" maxOccurs="unbounded" />
               <element ref="iris:searchContinuation"
                 minOccurs="0" maxOccurs="unbounded" />
             </sequence>
           </complexType>
         </element>
         <element name="additional"
           minOccurs="0" maxOccurs="1">
           <complexType>
             <sequence>
               <element ref="iris:result"
                 minOccurs="0" maxOccurs="unbounded" />
             </sequence>
           </complexType>
         </element>
         <element name="insufficientResources"
           minOccurs="0" maxOccurs="1"
           type="iris:codeType" />
         <element name="invalidName"
           minOccurs="0" maxOccurs="1"
           type="iris:codeType" />
         <element name="invalidSearch"
           minOccurs="0" maxOccurs="1"
           type="iris:codeType" />
         <element name="limitExceeded"
           minOccurs="0" maxOccurs="1"
           type="iris:codeType" />


10. Security Considerations

   IRIS provides no authentication or privacy facilities of its own.  It
   relies on the application-transport layer for all of these abilities.
   Implementers need to fully understand the application-transports
   employed by IRIS.

   Referral IRIS registry results may contain entity lookups and search
   continuations which result in a client query operation against
   another registry service.  The authentication credentials and
   mechanisms subject to replay attacks SHOULD NOT be used to conduct a
   subsequent entity lookup or search continuation.







































Newton                  Expires May December 5, 2003               [Page 18] 34]

Internet-Draft                 iris-core                       June 2003


References

   [1]   Newton, A., "Cross Registry Internet Service Protocol (CRISP)
         Requirements", draft-ietf-crisp-requirements-00 (work in
         progress), August 2002.

   [2]   Newton, A., "Using the Internet Registry Information Service
         (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)",
         draft-ietf-crisp-iris-beep-01 (work in progress), October 2002.

   [3]   Newton, A., "IRIS Domain Registry Schema",
         draft-ietf-crisp-iris-dreg-01 (work in progress), October 2002.

   [4]   Newton, A., "IRIS Address Registry Schema",
         draft-ietf-crisp-iris-areg-01 (work in progress), October 2002.

   [5]   World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/
         REC-xml-19980210>.

   [6]   World Wide Web Consortium, "Namespaces in XML", W3C XML
         Namespaces, January 1999, <http://www.w3.org/TR/1999/
         REC-xml-names-19990114>.

   [7]   World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
         XML Schema, October 2000, <http://www.w3.org/TR/2001/
         REC-xmlschema-2-20010502/>.

   [8]   World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
         XML Schema, October 2000, <http://www.w3.org/TR/2001/
         REC-xmlschema-1-20010502/>.

   [9]   World Wide Web Consortium, "Extensible Stylesheet Language
         (XSL) Version 1.0", W3C XSL, November 2002


         <element name="nameNotFound"
           minOccurs="0" maxOccurs="1"
           type="iris:codeType" />
         <element name="permissionDenied"
           minOccurs="0" maxOccurs="1"
           type="iris:codeType" />
         <element ref="iris:genericCode"
           minOccurs="0" maxOccurs="1" />
       </sequence>
     </complexType>

     <complexType name="resultType">
       <attribute name="thisEntityURI"
         use="required"
         type="anyURI" />
     </complexType>

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

     <complexType name="searchContinuationType">
       <sequence>
         <element name="authority" type="token"
           minOccurs="1" maxOccurs="1" />
         <element name="searchSet"
           type="iris:searchSetType"
           minOccurs="1" maxOccurs="1"/>
       </sequence>
       <attribute name="thisEntityURI"
         type="anyURI" />
     </complexType>

     <element name="searchContinuation"
       type="iris:searchContinuationType" />

     <element name="genericCode" type="iris:codeType"
       abstract="true" />

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

     <complexType name="serializedNamedQueryType">
       <sequence>
         <element name="resultSet"
           type="iris:resultSetType" />
       </sequence> 2000, <http://www.w3.org/
         TR/2000/CR-xsl-20001121/>.

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

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

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

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



Newton                  Expires May December 5, 2003               [Page 19] 35]

Internet-Draft                 iris-core                       June 2003


   [14]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
         June 1999.

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

   [16]  Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-03 (work in progress),
         November 2002


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

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

     <complexType name="serviceIdentificationType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>
             <element name="authorities"
               minOccurs="1" maxOccurs="1">
               <complexType>
                 <sequence>
                   <element name="authority" type="token"
                     minOccurs="1" maxOccurs="unbounded" />
                 </sequence>
               </complexType>
             </element>
             <element name="eMail" type="string"
               minOccurs="0" maxOccurs="1" />
             <element name="phone" type="string"
               minOccurs="0" maxOccurs="1" />
             <element ref="iris:seeAlso"
               minOccurs="0" maxOccurs="1" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="serviceIdentification"
       type="iris:serviceIdentificationType"
       substitutionGroup="iris:result" />

     <complexType name="simpleEntityType">
       <complexContent> 2001.

   [17]  Daigle, L. and A. Newton, "Domain-based Application Service
         Location Using SRV RRs and the Dynamic  Delegation Discovery
         Service (DDDS)", draft-daigle-napstr-01 (work in progress),
         November 2002.

   [18]  Daigle, L. and A. Newton, "Lightweight Internet Registry
         Information Service", draft-newton-iris-lightweight-00 (work in
         progress), February 2003.

   [19]  Daigle, L., "IRIS Certificate and Key Registry",
         draft-daigle-iris-credreg-00 (work in progress), February 2003.

   [20]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [21]  The Unicode Consortium, "The Unicode Standard, Version 2.0",
         ISBN 0-201-48345-9 ISBN 0-201-48345-9, January 1988, <The
         Unicode Standard, Version 2.0>.

   [22]  Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
         2.0", RFC 1866, November 1995.

   [23]  Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
         IPv6 Addresses in URL's", RFC 2732, December 1999.

   [24]  Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
         954, October 1985.

   [25]  <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>












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


         <extension base="iris:resultType">
           <sequence>
             <element name="property"
               minOccurs="1" maxOccurs="unbounded">
               <complexType>
                 <simpleContent>
                   <extension base="string">
                     <attribute name="name" type="string"
                       use="required" />
                     <attribute name="language" type="language"
                       use="required" />
                   </extension>
                 </simpleContent>
               </complexType>
             </element>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

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

   </schema>                       June 2003


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 May December 5, 2003               [Page 21] 37]

Internet-Draft                 iris-core                  November 2002


6. Internationalization Considerations

   IRIS is represented in XML, which provides native support for
   encoding information using the double-byte Unicode character set                       June 2003


Appendix A. NAPSTR and
   its more compact representations including UTF-8.  Compliant XML
   processors IRIS Uses

A.1 An Examples of NAPSTR with IRIS

   This section shows an example use of NAPSTR [17] by IRIS.  In this
   example, there are required to understand both UTF-8 two registry types: REGA and raw Unicode
   character sets; XML REGB.  There are also includes a provision for identifying other
   character sets through
   two IRIS application transports: iris-a and iris-b.  Given this, the
   use of NAPSTR offers the following:

   1.  A means to allow an "encoding" attribute in an <?xml?>
   processing instruction.  The complete list operator to split out the set of character servers
       running REGA from the set encoding
   identifiers of servers running REGB.  This is maintained by IANA and to
       say, the operator is described in  [17] and [12].

   The application-transport layer MUST define a common able to split out the set of character servers serving
       up data for REGA from the set encodings to be understood by both client and server.

   Localization of internationalized strings may require additional
   information by the client.  Entity definitions SHOULD use the
   "language" type defined by XML_SD [7] servers serving up data for
       REGB.

   2.  A means to aid clients in the
   localization process.  See Section 3.3.6.2 as allow an example.

































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


7. IANA Considerations

   XML schemas require a URI for unique identification.  Schemas MUST be
   registered operator to ensure URI uniqueness, but the IETF does not currently
   have a recommended repository for specify which set of servers are
       running iris-a from the registration set of XML schemas. servers running iris-b.  This document uses URNs is
       to describe XML namespaces and XML schemas.
   IANA SHOULD maintain a registry say, the operator is able to split out the set of XML namespace and schema URI
   assignments.  Per policies described in [13], URI assignment requests
   SHOULD be reviewed by a designated expert, servers
       running protocol iris-a serving REGA and values SHOULD be
   assigned only as a result of standards action taken by REGB data from the IESG.

   This document makes use set
       of a proposed XML namespace servers running protocol iris-b serving REGA and schema
   registry specified in XML_URN [16].  Accordingly, the following URN
   will need REGB data.

   3.  A means to be registered with IANA:

      urn:ietf:params:xml:ns:iris1



































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


8. Security Considerations

   IRIS provides no authentication or privacy facilities allow an operator to specify which set of its own.  It
   relies on the application-transport layer for all of these abilities.
   Implementers need servers
       to fully understand the application-transports
   employed by IRIS.

   Referral IRIS registry results may contain entity lookups operate and search
   continuations which result in a client query operation against
   another registry service.  The authentication credentials and
   mechanisms subject set of the above servers to replay attacks SHOULD NOT be used delegate to conduct a
   subsequent entity lookup or search continuation.
       another operator.

   To implement the first feature, the operator deploys the following in
   their DNS zone:

   example.com.
   ;;        order  pref  flags service                 re replacement
   IN NAPTR  100    10    ""    "REGA:iris-a:iris-b"    "" example.com
   IN NAPTR  100    10    ""    "REGB:iris-a:iris-b"    "" example.com

   To implement the second feature, the operator then adds the following
   in their DNS zone:
















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


References

   [1]   Newton, A., "Cross Registry Internet Service Protocol (CRISP)
         Requirements", draft-ietf-crisp-requirements-00 (work in
         progress), August 2002.

   [2]   Newton, A., "Using                       June 2003


   example.com.
   ;;        order  pref  flags  service        re  replacement
   IN NAPTR  100    10    "s"    "REGA:iris-a"  ""  _iris-a._udp.example.com
   IN NAPTR  100    10    "s"    "REGA:iris-b"  ""  _iris-b._tcp.example.com

   _iris-a._udp.example.com.
   ;;        pref  weight port  target
   IN SRV    10    0      34    big-a.example.com.
   IN SRV    20    0      34    small-a.example.com.

   _iris-b._tcp.example.com.
   ;;        pref  weight port  target
   IN SRV    10    0      34    big-b.example.com.
   IN SRV    20    0      34    small-b.example.com.

   Finally, an operator may decide to operate the REGA services while
   delegating the REGB services to somebody else.  Here is how that is
   done:

   example.com.
   ;;       order pref flags service              re replacement
   IN NAPTR 100   10   ""    "REGA:iris-a:iris-b" "" example.com
   IN NAPTR 100   10   ""    "REGB:iris-a:iris-b" "" somebodyelse.com

   Or the Internet Registry Information Service
         (IRIS) over operator may decide to operate REGB services under the Blocks Extensible Exchange Protocol (BEEP)",
         draft-ietf-crisp-iris-beep-01 (work in progress), October 2002.

   [3]   Newton, A., "IRIS Domain Registry Schema", draft-ietf-crisp-
         iris-dreg-01 (work in progress), October 2002.

   [4]   Newton, A., "IRIS Address Registry Schema", draft-ietf-crisp-
         iris-areg-01 (work in progress), October 2002.

   [5]   World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
         xml-19980210>.

   [6]   World Wide Web Consortium, "Namespaces iris-a
   protocol/transport while delegating the REGB services under the
   iris-b protocol/transport to somebody else.

   example.com.
   ;;       order pref flags service       re replacement
   IN NAPTR 100   10   ""    "REGB:iris-a:iris-b" "" example.com
   IN NAPTR 100   10   "s"   "REGB:iris-a" "" _iris-a._udp.example.com
   IN NAPTR 100   10   "s"   "REGB:iris-b" "" _iris-b._tcp.somebodyelse.com

   _iris-a._udp.example.com.
   ;;        pref  weight port  target
   IN SRV    10    0      34    big-a.example.com.
   IN SRV    20    0      34    small-a.example.com.

   Note that while this last example is possible, it is probably not
   advisable because of the operational issues involved in XML", W3C XML
         Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-
         names-19990114>.

   [7]   World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
         XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
         xmlschema-2-20010502/>.

   [8]   World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
         XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
         xmlschema-1-20010502/>.

   [9]   World Wide Web Consortium, "Extensible Stylesheet Language
         (XSL) Version 1.0", W3C XSL, November 2000, <http://www.w3.org/
         TR/2000/CR-xsl-20001121/>.

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

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

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

   [13]  Narten, T. synchronizing
   the data between example.com and H. Alvestrand, "Guidelines for Writing somebodyelse.com.  It is provided
   here as an IANA
         Considerations Section example of what is possible.

A.2 Using NAPSTR for Cohabitation

   Given the examples in RFCs", RFC 2434, BCP 26, October
         1998. Appendix A.1, the use of NAPSTR could be part
   of a transition strategy for cohabitation of protocols solving the



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


   [14]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
         June 1999.

   [15]  Bradner, S., "Key words                       June 2003


   problems of CRISP [1].

   For example, the type of data for use in RFCs domain information could be given
   the application service label of "CRISP-DOMAIN".  Given this, the
   service field of a NAPTR record could read:

      "CRISP-DOMAIN:whois:iris-beep"

   This service field conveys that domain data, as defined by CRISP, is
   available both via the iris-beep protocol and the whois protocol.
   The whois application protocol label refers to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [16]  Mealling, M., "The IETF XML Registry", draft-mealling-iana-
         xmlns-registry-03 (work in progress), November 2001.

   [17]  <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>


Author's Address

   Andrew L. Newton
   VeriSign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   USA

   Phone: +1 703 948 3382
   EMail: anewton@ecotroph.net
   URI:   http://www.verisignlabs.com/ 954 [24].

   Another example of this would be:

      "CRISP-DOMAIN:iris-beep:ldap"

   where the data is available via both IRIS and LDAP.


































Newton                  Expires May December 5, 2003               [Page 26] 40]

Internet-Draft                 iris-core                  November 2002                       June 2003


Appendix A. B. Document Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [15].














































Newton                  Expires May December 5, 2003               [Page 27] 41]

Internet-Draft                 iris-core                  November 2002                       June 2003


Appendix B. C. 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.  In addition, Leslie has provided great insight into the
   details of URI's, URN's, and NAPTR/SRV resource records.

   Many other technical complexities were proved to be unnecessary by
   David Blacka and have been removed.  And his IRIS implementation has
   helped smooth out the rougher edges.








































Newton                  Expires May December 5, 2003               [Page 28] 42]

Internet-Draft                 iris-core                  November 2002                       June 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2002). (2003).  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. assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Newton                  Expires December 5, 2003               [Page 43]

Internet-Draft                 iris-core                       June 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Newton                  Expires May December 5, 2003               [Page 29] 44]

----