Internet Registry Information Service
From: http://www.ietf.org/internet-drafts/draft-newton-iris-00.txt

---------------------------------------------------------------------------

Network Working Group                                          A. Newton
Internet-Draft                                            VeriSign, Inc.
Expires: August 20, 2002                               February 19, 2002


                 Internet Registry Information Service
                          draft-newton-iris-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on August 20, 2002.

Copyright Notice

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

Abstract

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









Newton                  Expires August 20, 2002                 [Page 1]

Internet-Draft                    iris                     February 2002


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Use of XML . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2   General Concepts . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Protocol Description . . . . . . . . . . . . . . . . . . . .  5
   2.1   Protocol Identification  . . . . . . . . . . . . . . . . . .  5
   2.2   Request Format . . . . . . . . . . . . . . . . . . . . . . .  6
   2.2.1 <authenticate> Request . . . . . . . . . . . . . . . . . . .  6
   2.2.2 <sessionInquiry> and <serviceInquiry> Request  . . . . . . .  6
   2.2.3 <registrySearch> Request . . . . . . . . . . . . . . . . . .  7
   2.2.4 <quit> Request . . . . . . . . . . . . . . . . . . . . . . .  7
   2.3   Response Format  . . . . . . . . . . . . . . . . . . . . . .  7
   2.3.1 <sessionStatus> Response . . . . . . . . . . . . . . . . . .  7
   2.3.2 <serviceResult> Response . . . . . . . . . . . . . . . . . .  8
   2.3.3 <registryResult> Response  . . . . . . . . . . . . . . . . .  8
   3.    Extension Framework  . . . . . . . . . . . . . . . . . . . . 10
   3.1   Derived Elements . . . . . . . . . . . . . . . . . . . . . . 10
   3.2   Namespace Identifier Requirements  . . . . . . . . . . . . . 10
   3.3   Names of Entities  . . . . . . . . . . . . . . . . . . . . . 11
   4.    URI Requirements . . . . . . . . . . . . . . . . . . . . . . 12
   5.    Formal XML Syntax  . . . . . . . . . . . . . . . . . . . . . 13
   6.    Internationalization Considerations  . . . . . . . . . . . . 19
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 20
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 21
         References . . . . . . . . . . . . . . . . . . . . . . . . . 22
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 23
   A.    Document Terminology . . . . . . . . . . . . . . . . . . . . 24
   B.    Outstanding Issues . . . . . . . . . . . . . . . . . . . . . 25
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 26





















Newton                  Expires August 20, 2002                 [Page 2]

Internet-Draft                    iris                     February 2002


1. Introduction

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

1.1 Use of XML

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

   It is important to note that XML is case sensitive.  XML
   specifications and examples provided in this document MUST be
   interpreted in the exact character case presented to develop a
   conforming implementation.

1.2 General Concepts

   Each of the three types of registries, address, routing, and domain,
   are considered to occupy their own namespace.  This registry
   namespace is identified by the URI, more specifically a URN, used
   within the XML instances to identify the XML schema formally
   describing the information service.

   A registry information server may handle queries and serve results
   for multiple registry namespaces.  Each registry namespace for which
   a particular registry operator serves is a registry information
   service instance.	      

   IRIS, and the XML schema formally describing IRIS, does not specify
   any registry, registry namespace, or knowledge of a particular
   service instance or set of instances.  IRIS is a specification for a
   framework with which these registry namespaces can be defined, used,
   and in some cases interoperate. The framework merely specifies the
   elements for session management and the elements which must be used
   to derive query elements and result elements.

   This framework allows a registry namespace to define its own
   structure for naming, entities, queries, etc. through the use XML
   namespaces and XML schemas (hence, a registry namespace is
   identified by the same URI that identifies its XML namespace).  In
   order to be useful, a registry namespace must extend from this
   framework.

   The framework does define certain structures that can be common to
   all namespaces, such as entity references, search continuations,


Newton                  Expires August 20, 2002                 [Page 3]

Internet-Draft                    iris                     February 2002


   authentication types, and more.  A registry namespace may declare
   its own definitions for all of these, or it may mix its derived
   definitions with the base definitions.

   IRIS defines two types of referrals, an entity reference and a
   search continuation.  An entity reference indicates specific
   knowledge about an individual entity, and a search continuation
   allows for distributed searches.  Both types may span differing
   registry namespaces and instances.  In addition, IRIS specifies
   requirements for representing entity references as URI's.  No
   assumptions or specifications are made about roots, bases, or meshes
   of entities.

   Finally, the IRIS framework attempts to be transport neutral. There
   is no default transport specification. 




































Newton                  Expires August 20, 2002                 [Page 4]

Internet-Draft                    iris                     February 2002


2. Protocol Description

   IRIS is an application layer protocol that can be layered over
   multiple transport protocols.  Each protocol data unit MUST be one
   and only one complete and valid XML instance.  The XML document MAY
   contain one request element and MAY contain one response element.

   The request element describes elements for a client to authenticate
   to a server, request session status information, inquire about the
   available information data sets, query an information data set, and
   close the session.

   The response element describes elements for a server to provide to a
   client session status, available information data sets, and results
   from an information query.

   No requirements are made concerning the synchronization of the
   request and the response in this document.  However, a transport
   mapping of IRIS MAY make such requirements if necessary.  Both the
   request and response elements have optional 'sessionToken'
   attributes to aid in synchronization.  In this specification they
   are OPTIONAL, however a transport mapping MAY require them.

   The definition of a session is dependent on the underlying
   transport, but is generally understood to be the context in which
   requests and responses are conducted with respect to authentication.

   The following description of the protocol does not describe every
   detailed aspect necessary for implementation.  While reading these
   following sections, please reference Section 5 for needed details on
   the formal XML specification.

2.1 Protocol Identification

   The root element of all IRIS instance documents must be <iris>. 
   This element identifies the start of the IRIS elements, the
   namespace used as the identifier for the IRIS namespace, and the
   location of the schema.  This element and the associated closing tag
   MUST be applied to all requests and responses sent by both clients
   and servers. 

   An example: 

     <iris xmlns="urn:iana:xmlns:iris1"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:iana:xmlns:iris1 iris.xsd">
     </iris>

   The use of the schema location URI in the <xsi:schemaLocation>


Newton                  Expires August 20, 2002                 [Page 5]

Internet-Draft                    iris                     February 2002


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

   Versioning of the IRIS protocol is accomplished by use of the
   namespace URI.  A change in the URI indicates a change of the
   underlying schema and therefore a new version of the protocol.

2.2 Request Format

   A <request> element holds children representing the different
   requests that can be made from a client to a server.  This element
   has one attribute, 'sessionToken'.  This attribute is a string of
   generated by the client and SHOULD NOT have any meaning to the
   server.  Its purpose is to provide a mechanism for use by the client
   to match requests with responses, and it MAY be absent or empty.

2.2.1 <authenticate> Request

   Providing a mechanism for authentication, this element may have
   children of <simpleAuthentication> or derivatives of
   <complexAuthentication>.  The simple case requires
   <authenticationId> and <authenticationPassword>. The complex case is
   an abstract element to be defined by in the namespace of registries.
   Each type MUST contain an attribute of 'registryNamespace'
   signifying the target registry namespace to apply this
   authentication.  The value of this element and the registry
   namespace of a derived complex authentication element MAY be
   different.

   A client MAY re-authenticate more than once during session using the
   <authenticate> request.  If re-authentication occurs with different
   credentials, all new requests are to be processed against the new
   credentials.  Outstanding requests are to be processed against the
   old credentials.

   The specification for a registry namespace MAY choose to explicitly
   deny authentication using <simpleAuthentication>.

2.2.2 <sessionInquiry> and <serviceInquiry> Request

   The <sessionInquiry> element allows the client to inquire about the
   current session it has with the server.  This element  has no
   content and no attributes.  Clients SHOULD start sessions with a
   session inquiry.



Newton                  Expires August 20, 2002                 [Page 6]

Internet-Draft                    iris                     February 2002


   The <serviceInquiry> element enables the client to query for  a list
   of registry namespace identifiers.  Authentication MUST not  be
   required for this request.

2.2.3 <registrySearch> Request

   The <registrySearch> element enables a client to query a  registry
   namespace of a registry service.  It may have two element types as
   children: <lookupEntity> and <query>.

   The content of the <lookupEntity> element is the name of an entity
   within a registry.  The 'registryNamespace' attribute is the
   namespace identifier for the namesapce in which the lookup operation
   is to take place.

   The <query> element is abstract and MAY NOT legally appear in an XML
   instance.  It provides the base type to be used by registry
   namespaces to define derived query types.

2.2.4 <quit> Request

   The <quit> element signals the clients intent to close the  session.
   If the <request> element containing a <quit>  element does not
   contain a <registrySearch>, <sessionInquiry>,  or <serviceInquiry>
   element, the server MUST immediately close  the session, else the
   server MUST respond with the results and then immediately close the
   session.

2.3 Response Format

   The <response> element holds children of the different response
   types returned from a server to a client.  This element has one
   attribute, 'sessionToken'.  This attribute is a string generated by
   the client and SHOULD NOT have any meaning to the server.  The value
   of this attribute MUST be identical to the value of the
   'sessionToken' attribute of the corresponding <request> element.

2.3.1 <sessionStatus> Response

   The <sessionStatus> element MUST be returned to the client in
   response to an <authenticate> or <sessionInquiry> request.  This
   element MUST also be returned to the client when authentication is
   required in response to <registrySearch> requests.

   The <sessionStatus> MUST contain one of these child elements: 

   o  <currentlyAuthenticated> MUST be the response if the client
      issues an <authenticate> request.  If the client issues a
      <sessionInquiry> request and the client is authenticated by means


Newton                  Expires August 20, 2002                 [Page 7]

Internet-Draft                    iris                     February 2002


      of a lower layer protocol, the server MUST respond with this
      answer.  If the client issues an <authenticate> request and is
      already authenticated by means of a lower layer protocol, the
      server MUST respond with this answer regardless of the
      authentication credentials in the <authenticate> method. 

   o  <authenticationRequired> MUST be the child of <sessionStatus> if
      authentication is required to proceed with any requests, or in
      response to a <sessionInquiry> request when the client is not
      authenticated. 

   o  <noAuthenticationRequired> MUST be the child of <sessionStatus>
      if no authentication is required, or in response to a
      <sessionInquiry> request when the client is not required to
      authenticate. 

   The <sessionStatus> element MAY contain the <communicationProblem>
   element.  This element signifies the failure to correctly parse the
   XML of the  corresponding request.

2.3.2 <serviceResult> Response

   The <serviceResult> element is a response to the <serviceInquiry>. 
   A server MAY require authentication before serving this information.
   If authentication is required and the client is not authenticated, a
   server  MUST return a <sessionStatus> element instead of a
   <serviceResult>  element.

   If the client is authenticated, this element MUST contain child
   elements of <registryNamespace>.  The contents of each child MUST
   contain one registry namespace identifier.  In this state, the
   <serviceResult> element MUST contain a <registryNamespace> child
   element for each registry namespace for which the server allows
   queries.

   A server MAY NOT require separate authentication credentials for
   this response than for the <registryResult> response.  In other
   words, if a client is authenticated to receive <registryResult>
   responses, then it MUST also be authenticated to receive these
   responses.

2.3.3 <registryResult> Response

   The <registryResult> element is a response to a <registrySearch>
   request.  Each child element is a response to a corresponding child
   element in the <registrySearch> request element, and the order of
   these children MUST be the same order as their corresponding request
   elements.



Newton                  Expires August 20, 2002                 [Page 8]

Internet-Draft                    iris                     February 2002


   The children MUST be one of the following types: 

   o  <result> is an abstract element and MAY NOT be legally placed in
      an XML instance.  It provides the base type to be used by
      registry namespaces to define derived result types.  A derivative
      of the <result> element MAY be followed by a <styleSheet>
      element.  The <styleSheet> element communicates to the client the
      location of a style sheet which MAY be used in the rendering of
      the contents of the <result> element. 

   o  The contents of <entityReference> is a URI.  This element
      notifies the client of a reference to an entity.  The URI SHOULD
      be an IRIS URI. Resolution of the URI is OPTIONAL by the client. 

   o  The <searchContinuation> element children MUST contain one
      <hostReference> element and one <registrySearch> element.
      Registry namespaces MAY derive a new type from <hostReference> to
      match transport protocol needs. 

   o  The following error elements: 

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

      *  <invalidName> - a name given in a query is not syntactically
         correct. 

      *  <invalidSearch> - parameters of the corresponding query are
         not semantically meaningful. 

      *  <limitExceeded> - the corresponding query requires more
         resources than allowed. 

      *  <nameNotFound> - the name given in a query does not match a
         known entity. 

      *  <permissionDenied> - the authentication given does not allow
         access to a specific result entry.  This is not the same as
         denying access to all <registryResult> responses because of
         failed authentication. 

      *  <invalidXML> - the XML of the registry namespace of the
         corresponding query does not validate. 








Newton                  Expires August 20, 2002                 [Page 9]

Internet-Draft                    iris                     February 2002


3. Extension Framework

   Because the IRIS schema defines no useful query types, no registry
   structure, and no result types, it is useless by itself. Extension
   of IRIS is accomplished through the use a base IRIS schema, as
   defined in [4] and [5], and extension of it by schemas constructed
   on top of IRIS. 

3.1 Derived Elements

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

   While the IRIS schema definition does not prohibit the derivation of
   any elements, registry namespace 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 MAY appear in an XML instance. 

   o  <result> - as defined this element contains no content and has no
      valid attributes.  It is abstract and therefore only derivatives
      of it MAY appear in an XML instance. 

   o  <hostReference> - as defined this element contains a <scheme>,
      <host>, and <port> elements.  Derivations SHOULD extend the
      content to include information necessary establishing sessions by
      lower layer protocols, but MUST NOT restrict derivations to
      content less than what is defined. 

   o  <complexAuthentication> - as defined this element contains no
      content and has one valid attribute, 'registryNamespace'.  It is
      abstract and therefore only derivatives of it MAY appear in an
      XML instance. Its purpose is to provide a means for the
      definition of authentication more complex than an identifier and
      password (i.e. XML PKI ). 

3.2 Namespace Identifier Requirements

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

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


Newton                  Expires August 20, 2002                [Page 10]

Internet-Draft                    iris                     February 2002


3.3 Names of Entities

   The names of entities in a registry namespace MUST be of type CDATA
   defined by [4].  They may not contain XML markup. Their use SHOULD
   be transcribable. 

   Names of entities SHOULD be unique within an instance of a registry
   namespace.  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 namespace 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. 





































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


4. URI Requirements

   IRIS does not have single URI definition because of the dependencies
   on a URI by the mapping between IRIS and a transport protocol. 
   However, any valid IRIS URI definition MUST meet the following
   requirements: 

   o  Using the layout form syntax of RFC2396[7], each IRIS URI MUST
      contain a <query> component within its <schema-specific-part>
      component.  The <query> component MUST be composed of the
      registry namespace identifier, a '/' (slash) character, and the
      name of an entity within the registry namespace . The layout form
      syntax of the <query> component MUST be: 

                   <registry-namespace>/<entity-name>

   o  The URI MUST be an absolute URI, therefore the scheme component
      is always present. 

   o  The URI MUST contain the <query> URI component as defined above.
      This component MUST contain the <registry-namespace> component
      and the <entity-name> component and therefore MUST always be an
      entity reference. 

   o  Each transport mapping MUST define a scheme name.  The scheme
      name MAY NOT be used by other IRIS transport mappings. 

   There is no default URI scheme or transport mapping. 























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


5. Formal XML Syntax

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


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

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

     <element name="iris">
       <complexType>
   	    <sequence>
   	      <element name="request"
   	        type="iris:requestType"
   	        minOccurs="0" maxOccurs="1" />
   	      <element name="response"
   	        type="iris:responseType"
   	        minOccurs="0" maxOccurs="1" />
   	    </sequence>
       </complexType>
     </element>

     <complexType name="requestType">
       <sequence>
   	    <element name="authenticate"
   	      type="iris:authenticateType"
   	      minOccurs="0" maxOccurs="1" />
   	    <element name="sessionInquiry"
   	      type="iris:sessionInquiryType"
   	      minOccurs="0" maxOccurs="1" />
   	    <element name="serviceInquiry"
   	      type="iris:serviceInquiryType"
   	      minOccurs="0" maxOccurs="1" />
   	    <element name="registrySearch"
   	      type="iris:registrySearchType"
   	      minOccurs="0" maxOccurs="unbounded" />
   	    <element name="quit"
   	      type="iris:quitType"
   	      minOccurs="0" maxOccurs="1" />


Newton                  Expires August 20, 2002                [Page 13]

Internet-Draft                    iris                     February 2002


       </sequence>
       <attribute name="sessionToken"
         type="string"
         use="optional" />
     </complexType>

     <complexType name="authenticateType">
       <choice minOccurs="1" maxOccurs="unbounded">
         <element name="simpleAuthentication"
           type="iris:simpleAuthenticationType" />
         <element ref="iris:complexAuthentication" />
       </choice>
     </complexType>

     <complexType name="simpleAuthenticationType">
       <sequence>
   	    <element name="authenticationId"
   	      type="string"
   	      minOccurs="1" maxOccurs="1" />
   	    <element name="authenticationPassword"
   	      type="string"
   	      minOccurs="1" maxOccurs="1" />
       </sequence>
       <attribute name="registryNamespace"
         type="anyURI" use="required" />
     </complexType>

     <complexType name="complexAuthenticationType">
       <attribute name="registryNamespace"
         type="anyURI" use="required" />
     </complexType>

     <element name="complexAuthentication"
       type="iris:complexAuthenticationType"
       abstract="true" />

     <complexType name="sessionInquiryType" />

     <complexType name="serviceInquiryType" />

     <complexType name="registrySearchType" >
       <choice>
         <element name="lookupEntity"
           type="iris:lookupEntityType" />
         <element ref="iris:query"
           minOccurs="1" maxOccurs="unbounded" />
       </choice>
     </complexType>



Newton                  Expires August 20, 2002                [Page 14]

Internet-Draft                    iris                     February 2002


     <complexType name="queryType"/>

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

     <complexType name="lookupEntityType" >
       <simpleContent>
         <extension base="string">
           <attribute name="registryNamespace"
             type="anyURI"
             use="required" />
         </extension>
       </simpleContent>
     </complexType>

     <complexType name="quitType" />

     <complexType name="responseType">
       <sequence>
   	    <element name="sessionStatus"
   	      type="iris:sessionStatusType"
   	      minOccurs="0" maxOccurs="1" />
   	    <element name="serviceResult"
   	      type="iris:serviceResultType"
   	      minOccurs="0" maxOccurs="1" />
   	    <element name="registryResult"
   	      type="iris:registryResultType"
   	      minOccurs="0" maxOccurs="unbounded" />
       </sequence>
       <attribute name="sessionToken"
         type="string" use="optional" />
     </complexType>

     <complexType name="sessionStatusType" >
       <sequence>
   	    <choice
   	      minOccurs="0" maxOccurs="unbounded" >
   	      <element name="currentlyAuthenticated"
   	        type="iris:authenticationCodeType" />
   	      <element name="authenticationRequired"
   	        type="iris:authenticationCodeType" />
   	      <element name="noAuthenticationRequired"
   	        type="iris:authenticationCodeType" />
   	    </choice>
   	    <element name="communicationProblem"
   	      type="iris:codeType"
   	      minOccurs="0" maxOccurs="1" />
       </sequence>


Newton                  Expires August 20, 2002                [Page 15]

Internet-Draft                    iris                     February 2002


     </complexType>

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

     <complexType name="authenticationCodeType">
       <sequence minOccurs="0" maxOccurs="1">
         <element name="explanation" type="string" />
         <element name="language" type="language" />
       </sequence>
       <attribute name="registryNamespace"
         type="anyURI" use="required" />
     </complexType>

     <complexType name="serviceResultType" >
       <sequence>
   	    <element name="registryNamespace"
   	      minOccurs="1" maxOccurs="unbounded">
   	      <complexType>
   	        <simpleContent>
   	          <extension base="anyURI">
                 <attribute name="location" type="anyURI"
                   use="required" />
               </extension>
             </simpleContent>
   	      </complexType>
   	    </element>
       </sequence>
     </complexType>

     <complexType name="registryResultType" >
       <choice minOccurs="0" maxOccurs="unbounded">
   	    <sequence>
   	      <element ref="iris:result"
   	        minOccurs="1" maxOccurs="1" />
   	      <element ref="iris:stylesheet"
   	        minOccurs="0" maxOccurs="1" />
   	    </sequence>
   	    <element name="entityReference"
   	      type="anyURI" />
   	    <element name="searchContinuation"
   	      type="iris:searchContinuationType" />
   	    <element name="insufficientResources"
   	      type="iris:codeType" />
   	    <element name="invalidName"


Newton                  Expires August 20, 2002                [Page 16]

Internet-Draft                    iris                     February 2002


   	      type="iris:codeType" />
   	    <element name="invalidSearch"
   	      type="iris:codeType" />
   	    <element name="limitExceeded"
   	      type="iris:codeType" />
   	    <element name="nameNotFound"
   	      type="iris:codeType" />
   	    <element name="permissionDenied"
   	      type="iris:codeType" />
   	    <element name="invalidXML"
   	      type="iris:codeType" />
   	    <element ref="iris:genericCode" />
       </choice>
     </complexType>

     <complexType name="resultType" />

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

     <complexType name="searchContinuationType">
       <sequence>
   	    <element ref="iris:hostReference"
   	      minOccurs="1" maxOccurs="1" />
   	    <element name="registrySearch"
   	      type="iris:registrySearchType"
   	      minOccurs="1" maxOccurs="1"/>
       </sequence>
     </complexType>

     <complexType name="hostReferenceType">
       <sequence>
   	    <element name="scheme" type="string"
   	      minOccurs="1" maxOccurs="1" />
   	    <element name="host" type="string"
   	      minOccurs="1" maxOccurs="1" />
   	    <element name="port" type="positiveInteger"
   	      minOccurs="1" maxOccurs="1" />
       </sequence>
     </complexType>

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

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

     <complexType name="stylesheetType" >


Newton                  Expires August 20, 2002                [Page 17]

Internet-Draft                    iris                     February 2002


       <attribute name="location"
         type="anyURI" use="required" />
       <attribute name="type"
         type="NMTOKEN" use="required" />
     </complexType>

     <element name="stylesheet"
       type="iris:stylesheetType"
       abstract="true" />

   </schema>








































Newton                  Expires August 20, 2002                [Page 18]

Internet-Draft                    iris                     February 2002


6. Internationalization Considerations

   IRIS is represented in XML, which provides native support for
   encoding information using the double-byte Unicode character set and
   its more compact representations including UTF-8.  Compliant XML
   processors are required to understand both UTF-8 and raw Unicode
   character sets; XML also includes a provision for identifying other
   character sets through use of an "encoding" attribute in an <?xml?>
   processing instruction. The complete list of character set encoding
   identifiers is maintained by IANA and is described in [13] and [9]. 









































Newton                  Expires August 20, 2002                [Page 19]

Internet-Draft                    iris                     February 2002


7. IANA Considerations

   XML schemas require a URI for unique identification.  Schemas MUST
   be registered to ensure URI uniqueness, but the IETF does not
   currently have a recommended repository for the registration of XML
   schemas. This document uses URNs to describe XML namespaces and XML
   schemas. IANA SHOULD maintain a registry of XML namespace and schema
   URI assignments.  Per policies described in [10], URI assignment
   requests SHOULD be reviewed by a designated expert, and values
   SHOULD be assigned only as a result of standards action taken by the
   IESG. 








































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


8. Security Considerations

   IRIS provides only a simple client authentication mechanism.  A
   passive attack is sufficient to recover client identifiers and
   passwords, allowing trivial session forgery.  Protection against
   most common attacks should be provided by the underlying transport
   protocol or protocols. 

   The simple client authentication mechanism uses a variant of the
   PLAIN SASL mechanism described in [11] to provide a
   application-layer authentication capability.  Where the PLAIN SASL
   mechanism specifies provision of an authorization identifier,
   authentication identifier, and password as a single string separated
   by ASCII NUL characters, IRIS specifies use of a combined
   authorization and authentication identifier and a password provided
   as distinct XML elements. 

   IRIS also allows for the definition of complex authentication
   mechanisms in registry namespaces which derive their schemas from
   IRIS.  The specification for these complex mechanisms MUST describe
   all relevant security considerations. 

   Repeated password guessing attempts can be discouraged by limiting
   the number of <authenticate> attempts that can be attempted on an
   open session.  A server MUST discontinue a session if three
   <authenticate> attempts are made with either an invalid client
   identifier, an invalid password, or both an invalid client
   identifier and an invalid password. 

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

   As specified, IRIS allows a valid XML instance to contain both a
   <request> and a <response>.  Applications and processes acting only
   as a client for a given session MUST issue an
   <authenticationRequired> in response to all<authenticate> requests
   regardless of the authentication identifier and password.
   Applications and processes MAY act in the role of both a client and
   server in a session. 









Newton                  Expires August 20, 2002                [Page 21]

Internet-Draft                    iris                     February 2002


References

   [1]   Newton, A. and S. Kerr, "Internet Registry Directory
         Requirements", Internet Draft, A Work In Progress, February
         2002.

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

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

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

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

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

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

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

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

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

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

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

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





Newton                  Expires August 20, 2002                [Page 22]

Internet-Draft                    iris                     February 2002


Author's Address

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

   Phone: +1 703 948 3382
   EMail: anewton@verisignlabs.com
   URI:   http://www.research.netsol.com/








































Newton                  Expires August 20, 2002                [Page 23]

Internet-Draft                    iris                     February 2002


Appendix A. Document Terminology

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














































Newton                  Expires August 20, 2002                [Page 24]

Internet-Draft                    iris                     February 2002


Appendix B. Outstanding Issues

   The following items will need further investigation for furture
   versions of this document.

   o  Incorporation of a query model using DNS SRV records similar to
      that specified in section 7 of draft-hall-ldap-whois-00.txt.

   o  Addition of an "entity" XML attribute for identifying in-line
      entities via a URI.

   o  Addition of an optional entity namespace to help server
      implementations narrow lookups to single indices.

   o  Modification to error codes to allow for registry-namespace
      specific errors.

   o  Addition of query limitation expressions and inquiries.

   o  Other things to adhere more strictly to the requirements of
      draft-newton-ir-dir-requirements-00.txt.






























Newton                  Expires August 20, 2002                [Page 25]

Internet-Draft                    iris                     February 2002


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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



















Newton                  Expires August 20, 2002                [Page 26]