idnits 2.17.1 

draft-ietf-crisp-iris-core-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Missing revision: the document name given in the document,
     'draft-ietf-crisp-iris-core', does not give the document revision number

  ~~ Missing draftname component: the document name given in the document,
     'draft-ietf-crisp-iris-core', does not seem to contain all the document
     name components required ('draft' prefix, document source, document name,
     and revision) -- see https://www.ietf.org/id-info/guidelines#naming for
     more information.

  == Mismatching filename: the document gives the document name as
     'draft-ietf-crisp-iris-core', but the file name used is
     'draft-ietf-crisp-iris-core-00'

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).
     
     Found 'MAY NOT' in this paragraph:
     
     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.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).
     
     Found 'MAY NOT' in this paragraph:
     
     o  <result> is an abstract element and MAY NOT be legally placed in
     an XML instance. It provides the base type to be used by registry schemas
     to define derived result types.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).
     
     Found 'MAY NOT' in this paragraph:
     
     IRIS defines one default entity class of "QUERY" which MAY NOT be
     redefined. This class is for the naming of canned queries by registries.
     Therefore an entity lookup of a canned query MAY result in a search
     continuation on the same registry. When used in URI's (see Section 4),
     this is a type of boot-strapping procedure. Therefore, the resolution of
     "iris://com/dreg1/QUERY/registrars" may result in the list of registrars
     currently registering domains. The set of canned queries are not
     specified by IRIS.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).
     
     Found 'MAY NOT' in this paragraph:
     
     o  Each transport mapping MUST define a URI scheme. The scheme name
     MAY NOT be used by other IRIS transport mappings.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (August 14, 2002) is 7924 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: '6' is defined on line 944, but no explicit reference
     was found in the text

  == Unused Reference: '11' is defined on line 961, but no explicit reference
     was found in the text

  == Outdated reference: A later version (-06) exists of
     draft-ietf-crisp-requirements-00

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-crisp-requirements (ref. '1')

  -- Possible downref: Non-RFC (?) normative reference: ref. '2'

  -- Possible downref: Non-RFC (?) normative reference: ref. '3'

  -- Possible downref: Non-RFC (?) normative reference: ref. '4'

  -- Possible downref: Non-RFC (?) normative reference: ref. '5'

  -- Possible downref: Non-RFC (?) normative reference: ref. '6'

  ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986)

  ** Obsolete normative reference: RFC 2141 (ref. '8') (Obsoleted by RFC 8141)

  ** Obsolete normative reference: RFC 1700 (ref. '9') (Obsoleted by RFC 3232)

  ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC
     5226)

  == Outdated reference: A later version (-05) exists of
     draft-mealling-iana-xmlns-registry-03

  ** Obsolete normative reference: RFC 3023 (ref. '14') (Obsoleted by RFC
     7303)

  -- Possible downref: Non-RFC (?) normative reference: ref. '15'


     Summary: 9 errors (**), 1 flaw (~~), 12 warnings (==), 9 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

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

1	Network Working Group                                          A. Newton
2	Internet-Draft                                            VeriSign, Inc.
3	Expires: February 12, 2003                               August 14, 2002

5	              Internet Registry Information Service (IRIS)
6	                       draft-ietf-crisp-iris-core

8	Status of this Memo

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

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

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

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

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

29	   This Internet-Draft will expire on February 12, 2003.

31	Copyright Notice

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

35	Abstract

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

44	Table of Contents

46	   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
47	   1.1   Use of XML . . . . . . . . . . . . . . . . . . . . . . . . .  3
48	   1.2   General Concepts . . . . . . . . . . . . . . . . . . . . . .  3
49	   1.3   Framework Layers . . . . . . . . . . . . . . . . . . . . . .  4
50	   1.4   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .  4
51	   2.    Protocol Description . . . . . . . . . . . . . . . . . . . .  6
52	   2.1   Protocol Identification  . . . . . . . . . . . . . . . . . .  6
53	   2.2   Request Format . . . . . . . . . . . . . . . . . . . . . . .  7
54	   2.2.1 <serviceInquiry> Request . . . . . . . . . . . . . . . . . .  7
55	   2.2.2 <registrySearch> Request . . . . . . . . . . . . . . . . . .  7
56	   2.3   Response Format  . . . . . . . . . . . . . . . . . . . . . .  7
57	   2.3.1 <messsageStatus> Response  . . . . . . . . . . . . . . . . .  7
58	   2.3.2 <serviceResult> Response . . . . . . . . . . . . . . . . . .  8
59	   2.3.3 <registryResult> Response  . . . . . . . . . . . . . . . . .  8
60	   3.    Extension Framework  . . . . . . . . . . . . . . . . . . . . 10
61	   3.1   Derived Elements . . . . . . . . . . . . . . . . . . . . . . 10
62	   3.2   Registry Identifier Requirements . . . . . . . . . . . . . . 11
63	   3.3   Entity Classes . . . . . . . . . . . . . . . . . . . . . . . 11
64	   3.4   Names of Entities  . . . . . . . . . . . . . . . . . . . . . 12
65	   3.5   References to Entities . . . . . . . . . . . . . . . . . . . 12
66	   4.    URI Requirements . . . . . . . . . . . . . . . . . . . . . . 13
67	   5.    Database Serialization . . . . . . . . . . . . . . . . . . . 14
68	   6.    Formal XML Syntax  . . . . . . . . . . . . . . . . . . . . . 17
69	   7.    Internationalization Considerations  . . . . . . . . . . . . 23
70	   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 24
71	   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 25
72	         References . . . . . . . . . . . . . . . . . . . . . . . . . 26
73	         Author's Address . . . . . . . . . . . . . . . . . . . . . . 27
74	   A.    Document Terminology . . . . . . . . . . . . . . . . . . . . 28
75	   B.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
76	   C.    Considerations on XML-based RPC's  . . . . . . . . . . . . . 30
77	         Full Copyright Statement . . . . . . . . . . . . . . . . . . 31

79	1. Introduction

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

84	1.1 Use of XML

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

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

98	1.2 General Concepts

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

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

111	   IRIS and the XML schema formally describing IRIS do not specify any
112	   registry, registry identifier, or knowledge of a particular service
113	   instance or set of instances. IRIS is a specification for a
114	   framework with which these registries can be defined, used, and in
115	   some cases interoperate. The framework merely specifies the elements
116	   for registry identification and the elements which must be used to
117	   derive query elements and result elements.

119	   This framework allows a registry type to define its own structure
120	   for naming, entities, queries, etc. through the use of XML
121	   namespaces and XML schemas (hence, a registry type is identified by
122	   the same URI that identifies its XML namespace). In order to be
123	   useful, a registry type's specification must extend from this
124	   framework.

126	   The framework does define certain structures that can be common to
127	   all registry types, such as references to entities, search
128	   continuations, entity classes, and more. A registry type may declare
129	   its own definitions for all of these, or it may mix its derived
130	   definitions with the base definitions.

132	   IRIS defines two types of referrals, an entity URI and a search
133	   continuation. An entity URI indicates specific knowledge about an
134	   individual entity, and a search continuation allows for distributed
135	   searches. Both types may span differing registry types and
136	   instances. No assumptions or specifications are made about roots,
137	   bases, or meshes of entities.

139	   Finally, the IRIS framework attempts to be transport neutral.

141	1.3 Framework Layers

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

146	                            ----------------------------
147	         Registry-Specific  |domain | address | routing|
148	                            ----------------------------
149	           Common-Registry  |          IRIS            |
150	                            ----------------------------
151	     Application-Transport  |      beep, etc...        |
152	                            ----------------------------

154	   The differing layers have the following responsibilities:

156	      Registry-Specific :: Defines queries, results, and entity classes
157	      of a specific type of registry. Each specific type of registry is
158	      identified by a URN.

160	      Common-Registry :: Defines base operations and semantics common
161	      to all registry types such as referrals, entity references, etc.
162	      It also defines the syntaxes for talking about specific registry
163	      types (using the registry ID's).

165	      Application-Transport :: Defines the mechanisms for
166	      authentication, message passing, connection and session
167	      management, etc. It also defines the URI syntax specific to the
168	      application-transport mechanism.

170	1.4 Definitions

172	   For clarity, the following definitions are supplied:

174	      registry identifier (ID) - The identifier used to specify a
175	      particular type of registry.

177	      registry type - A registry serving a specific function, such as a
178	      domain registry or an address registry. Each type of registry is
179	      assigned a registry identifier.

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

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

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

190	      entity URI - A formal pointer to an entity. This URI contains a
191	      registry ID, entity class, and entity name.

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

197	2. Protocol Description

199	   Each protocol data unit MUST be one and only one complete and valid
200	   XML instance. The XML instance MUST contain either one request
201	   element or one response element.

203	   No requirements are made concerning the synchronization of the
204	   request and the response in this document. However, a transport
205	   mapping of IRIS MAY make such requirements if necessary. In
206	   addition, no methods are provided in this document for session or
207	   connection creation or termination; a transport mapping of IRIS MAY
208	   make such requirements if necessary.

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

215	2.1 Protocol Identification

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

223	   An example:

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

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

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

244	2.2 Request Format

246	   A <request> element holds children representing the different
247	   requests that can be made from a client to a server.

249	2.2.1 <serviceInquiry> Request

251	   The <serviceInquiry> element enables the client to query for a list
252	   of registry identifiers.

254	2.2.2 <registrySearch> Request

256	   The <registrySearch> element enables a client to query a particular
257	   registry identified by its registry ID. It may have two element
258	   types as children: <lookupEntity> and <query>.

260	   The children of the <lookupEntity> element are the <entityName> and
261	   <entityClass> elements. The 'registryID' attribute is the registry
262	   identifier for the registry type in which the lookup operation is to
263	   take place. The <entityClass> element MUST contain the token
264	   identifying the index for which the lookup operation is to take
265	   place, and the <entityName> element MUST contain the name of the
266	   entity to lookup.

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

272	2.3 Response Format

274	   The <response> element holds children of the different response
275	   types returned from a server to a client.

277	2.3.1 <messsageStatus> Response

279	   The <messsageStatus> element MUST be returned to the client in
280	   response to any errors that would have disabled the processing of
281	   the corresponding request.

283	   The <messsageStatus> MUST contain one of these child elements:

285	   o  <invalidXML> MUST be the response if the server is unable to
286	      correctly parse the corresponding request according to the rules
287	      of [5] and [4].

289	   o  <systemError> MUST be the response if the server is unable to
290	      process the corresponding request for any other reason.

292	2.3.2 <serviceResult> Response

294	   The <serviceResult> element is a response to the <serviceInquiry>.

296	   This element MUST contain child elements of <registryID>. The
297	   contents of each child MUST contain one registry identifier. The
298	   <serviceResult> element MUST contain a <registryID> child element
299	   for each registry type for which the server allows queries.

301	2.3.3 <registryResult> Response

303	   The <registryResult> element is a response to a <registrySearch>
304	   request.

306	   The children MUST be one of the following types:

308	   o  <result> is an abstract element and MAY NOT be legally placed in
309	      an XML instance. It provides the base type to be used by registry
310	      schemas to define derived result types.

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

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

321	   o  The following error elements:

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

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

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

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

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

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

343	      *  A derivative of <genericCode>.

345	3. Extension Framework

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

353	3.1 Derived Elements

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

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

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

369	   o  <result> - as defined this element contains no content and has no
370	      valid attributes. It is abstract and therefore only derivatives
371	      of it MUST appear in an XML instance. Registry schemas derive
372	      from this element to define results that may be returned from a
373	      query.

375	   o  <genericCode> - as defined, this element is an instance of
376	      codeType. Registry schemas MUST derive from this element and MUST
377	      NOT use it as it is an abstract element. It MAY contain the
378	      elements <explanation> and <language> to further describe the
379	      nature of the error.

381	   o  <entityClass> - as defined this element represents the identifier
382	      for an entity class. Registry schemas SHOULD derive from this
383	      element or MAY use it directly.

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

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

397	3.2 Registry Identifier Requirements

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

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

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

412	   In certain circumstances when registry identifiers are URN's defined
413	   by XML_URN[13] and the class component is "ns", they MAY be
414	   abbreviated to the part following the class component and its
415	   separator of the URN. For example, the full URN
416	   "urn:ietf:params:xml:ns:dreg1" may be abbreviated to "dreg1", but
417	   the full URN "urn:otherOrg:ns:myreg1" cannot be abbreviated. The use
418	   of this abbreviation MUST be specifically noted for the set of
419	   conditions where it may be used, otherwise the full URN MUST be
420	   used. These circumstances and conditions MUST be specified in other
421	   sections of this document and other documents related to IRIS where
422	   it is used.

424	   This abbreviation MUST NOT be used inside of XML instances in use
425	   with IRIS where XML Schema[4] specifies the use of a URI for schema
426	   identification or where XML_NS[3] specifies the use of a URI for XML
427	   namespace identification.

429	3.3 Entity Classes

431	   Entity classes are provided in IRIS to help avoid collisions with
432	   entity names with in any given registry type. Their specification in
433	   queries also allows server implementations to quickly narrow search
434	   or lookup scopes to a single index. A registry schema derives the
435	   list of valid entity classes from the <entityClass> element.

437	   For instance, the entity name "10.0.1.1" would refer to separate
438	   entities in the "nameServer" and "network" classes. The entity
439	   "10.0.1.1" in the "nameServer" class may refer to the name server
440	   host that is also multi-homed by address 192.178.0.1 and known in
441	   DNS as "ns.foo.com", whereas the entity "10.0.1.1" in the "network"
442	   class may refer to the network 10.0.1/24.

444	   IRIS defines one default entity class of "QUERY" which MAY NOT be
445	   redefined. This class is for the naming of canned queries by
446	   registries. Therefore an entity lookup of a canned query MAY result
447	   in a search continuation on the same registry. When used in URI's
448	   (see Section 4), this is a type of boot-strapping procedure.
449	   Therefore, the resolution of "iris://com/dreg1/QUERY/registrars" may
450	   result in the list of registrars currently registering domains. The
451	   set of canned queries are not specified by IRIS.

453	3.4 Names of Entities

455	   The names of entities in a registry schema MUST be of type
456	   normalizedString defined by XML_SD[4]. Their use SHOULD be
457	   transcribable.

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

469	   When specifying elements that represent entities, registry schemas
470	   SHOULD attach the attribute of "thisEntityURI" with the datatype of
471	   anyURI as specified by XML_SD[4]. This aids clients in understanding
472	   which parts of a result set represent an entity. The URI value in
473	   the XML instance SHOULD be an IRIS URI.

475	3.5 References to Entities

477	   The element <entityURI> allows references to entities in result
478	   sets, either as a direct child of <registryResult> or within a more
479	   complex structure that derives from <result>. Registry schemas MUST
480	   NOT derive elements from this element so that clients will have a
481	   better understanding of what is and what isn't an entity reference.
482	   This is especially useful to clients when dealing with XML
483	   conversion technologies such as XPath.

485	4. URI Requirements

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

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

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

503	   o  The URI MUST contain the <query> URI component as defined above.
504	      This component MUST contain the <registry-id> component, the
505	      <entity-class> component, and the <entity-name> component and
506	      therefore MUST always be an IRIS entity reference.

508	   o  The <registry-id> component MAY be abbreviated according to
509	      Section 3.2.

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

514	5. Database Serialization

516	   A database of IRIS entities can be serialized to file storage with
517	   XML[2] using the IRIS defined <irisSerialization> element. This
518	   element MUST only contain children which are a derivative of the
519	   <result> element, which SHOULD be elements describing entities.

521	   Because fragmentation is not defined in URI's for XML media
522	   types[14], the "file:" URI scheme cannot be safely used for
523	   serialization of entity URI's. Therefore, serialization of IRIS
524	   entity references SHOULD use the <serializedEntityURI> element
525	   instead of the <entityURI> element. This element is a derivative of
526	   the <entityURI> element. It contains the REQUIRED attributes
527	   "registryID", "entityClass", and "entityName". These attributes MUST
528	   be used to denote the unique identification of an entity. In
529	   addition, the OPTIONAL attribute "fileName" may also be used to
530	   specify the name of a file where the entity can be found.

532	   The actual content of the <serializedEntityURI> element MUST conform
533	   to the datatype of anyURI. A serialization process SHOULD attempt to
534	   formulate a valid IRIS URI to be placed in this element. If an
535	   element describing an entity contains the "thisEntityURI" attribute
536	   as specified in Section 3.4, the value of this URI should be equal
537	   to the value of the URI in any <serializedEntityURI> element
538	   referring to it.

540	   The following is an example of serialized IRIS.

542	   <?xml version="1.0"?>
543	   <irisSerialization xmlns="urn:ietf:params:xml:ns:iris1"
544	     xmlns:iris="urn:ietf:params:xml:ns:iris1"
545	     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
546	     xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >

548	     <dreg:domain
549	       xmlns="urn:ietf:params:xml:ns:dreg1"
550	       xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
551	       xsi:schemaLocation="urn:ietf:params:xml:ns:dreg1 dreg.xsd"
552	       thisEntityURI="iris://com/dreg1/domainHandle/tcs-com-1" >
553	       <domainName>thecobblershoppe.com</domainName>
554	       <nameServers>
555	         <iris:serializedEntityURI
556	           registryID="dreg1"
557	           entityClass="hostHandle"
558	           entityName="research7"
559	           fileName="iris-out.xml">
560	           iris://com/dreg1/hostHandle/research7
561	         </iris:serializedEntityURI>
562	         <iris:serializedEntityURI
563	           registryID="dreg1"
564	           entityClass="hostHandle"
565	           entityName="nsol184"
566	           fileName="iris-out.xml">
567	           iris://com/dreg1/hostHandle/nso1184
568	         </iris:serializedEntityURI>
569	       </nameServers>
570	       <holder>
571	         <contactHandle>beb140</contactHandle>
572	         <commonName>
573	           Bill Eckels
574	         </commonName>
575	         <organization>
576	           The Cobbler Shoppe
577	         </organization>
578	         <e-mail>
579	           bille@bjmk.com
580	         </e-mail>
581	         <address>
582	           21 North Main Street
583	         </address>
584	         <city>
585	           Britt
586	         </city>
587	         <region>
588	           IA
589	         </region>
590	         <postalCode>
591	           50423
592	         </postalCode>
593	         <country>
594	           US
595	         </country>
596	         <phone>
597	           515-843-3521
598	         </phone>
599	       </holder>
600	       <registry>
601	         <iris:serializedEntityURI
602	           registryID="dreg1"
603	           entityClass="contactHandle"
604	           entityName="VGRS"
605	           fileName="iris-out1.xml">
606	           iris://com/dreg1/contactHandle/VGRS
607	         </iris:serializedEntityURI>
608	       </registry>
609	     </dreg:domain>
610	     <dreg:host
611	       xmlns="urn:ietf:params:xml:ns:dreg1"
612	       xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
613	       xsi:schemaLocation="urn:ietf:params:xml:ns:dreg1 dreg.xsd"
614	       thisEntityURI="iris://com/dreg1/hostHandle/nsol184" >
615	       <hostHandle>nsol184</hostHandle>
616	       <hostName>ns1.netsol.com</hostName>
617	       <ipV4Address>216.168.224.200</ipV4Address>
618	       <iris:serializedEntityURI
619	         registryID="dreg1"
620	         entityClass="contactHandle"
621	         entityName="mak21"
622	         fileName="iris-out.xml">
623	         iris://com/dreg1/contactHandle/mak21
624	       </iris:serializedEntityURI>
625	     </dreg:host>

627	   </irisSerialization>

629	6. Formal XML Syntax

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

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

641	     <annotation>
642	       <documentation>
643	         Internet Registry Information Service (IRIS) Schema v1
644	       </documentation>
645	     </annotation>

647	     <element name="iris">
648	       <complexType>
649	         <choice>
650	           <element name="request"
651	             type="iris:requestType"
652	             minOccurs="0" maxOccurs="1" />
653	           <element name="response"
654	             type="iris:responseType"
655	             minOccurs="0" maxOccurs="1" />
656	         </choice>
657	       </complexType>
658	     </element>

660	     <complexType name="requestType">
661	       <sequence>
662	         <element name="serviceInquiry"
663	           type="iris:serviceInquiryType"
664	           minOccurs="0" maxOccurs="1" />
665	         <element name="registrySearch"
666	           type="iris:registrySearchType"
667	           minOccurs="0" maxOccurs="unbounded" />
668	       </sequence>
669	     </complexType>

671	     <complexType name="serviceInquiryType" />

673	     <complexType name="registrySearchType" >
674	       <choice>
675	         <element name="lookupEntity"
676	           type="iris:lookupEntityType" />

678	         <element ref="iris:query" />
679	       </choice>
680	     </complexType>

682	     <complexType name="queryType"/>

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

688	     <simpleType name="entityClassType">
689	       <restriction base="token">
690	       </restriction>
691	     </simpleType>

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

696	     <simpleType name="entityURIType">
697	       <restriction base="anyURI" />
698	     </simpleType>

700	     <simpleType name="thisEntityURIType">
701	       <restriction base="anyURI" />
702	     </simpleType>

704	     <simpleType name="baseentityClassType">
705	       <restriction base="iris:entityClassType">
706	         <enumeration value="QUERY" />
707	       </restriction>
708	     </simpleType>

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

714	     <complexType name="lookupEntityType" >
715	       <sequence>
716	         <element name="entityName" type="token" />
717	         <element ref="iris:entityClass" />
718	       </sequence>
719	       <attribute name="registryID"
720	         type="anyURI" use="required" />
721	     </complexType>

723	     <complexType name="responseType">
724	       <sequence>
725	         <element name="messageStatus"
726	           type="iris:messageStatusType"
727	           minOccurs="0" maxOccurs="1" />
728	         <element name="serviceResult"
729	           type="iris:serviceResultType"
730	           minOccurs="0" maxOccurs="1" />
731	         <element name="registryResult"
732	           type="iris:registryResultType"
733	           minOccurs="0" maxOccurs="unbounded" />
734	       </sequence>
735	     </complexType>

737	     <complexType name="messageStatusType" >
738	       <sequence>
739	         <choice>
740	           <element name="invalidXML"
741	             type="iris:codeType"
742	             minOccurs="0" maxOccurs="1" />
743	           <element name="systemError"
744	             type="iris:codeType"
745	             minOccurs="0" maxOccurs="1" />
746	         </choice>
747	       </sequence>
748	     </complexType>

750	     <complexType name="codeType">
751	       <sequence minOccurs="0" maxOccurs="1">
752	         <element name="explanation" type="string" />
753	         <element name="language" type="language" />
754	       </sequence>
755	     </complexType>

757	     <complexType name="serviceResultType" >
758	       <sequence>
759	         <element name="registryID"
760	           minOccurs="1" maxOccurs="unbounded">
761	           <complexType>
762	             <simpleContent>
763	               <extension base="anyURI">
764	                 <attribute name="location" type="anyURI"
765	                   use="required" />
766	               </extension>
767	             </simpleContent>
768	           </complexType>
769	         </element>
770	       </sequence>
771	     </complexType>

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

776	     <complexType name="seeAlsoType">
777	       <sequence>
778	         <element ref="iris:entityURI"
779	           minOccurs="1" maxOccurs="unbounded" />
780	       </sequence>
781	     </complexType>

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

785	     <complexType name="registryResultType" >
786	       <sequence>
787	         <element ref="iris:result"
788	           minOccurs="0" maxOccurs="unbounded" />
789	         <element ref="iris:entityURI"
790	           minOccurs="0" maxOccurs="unbounded" />
791	         <element name="searchContinuation"
792	           minOccurs="0" maxOccurs="unbounded"
793	           type="iris:searchContinuationType" />
794	         <element name="insufficientResources"
795	           minOccurs="0" maxOccurs="1"
796	           type="iris:codeType" />
797	         <element name="invalidName"
798	           minOccurs="0" maxOccurs="1"
799	           type="iris:codeType" />
800	         <element name="invalidSearch"
801	           minOccurs="0" maxOccurs="1"
802	           type="iris:codeType" />
803	         <element name="limitExceeded"
804	           minOccurs="0" maxOccurs="1"
805	           type="iris:codeType" />
806	         <element name="nameNotFound"
807	           minOccurs="0" maxOccurs="1"
808	           type="iris:codeType" />
809	         <element name="permissionDenied"
810	           minOccurs="0" maxOccurs="1"
811	           type="iris:codeType" />
812	         <element ref="iris:genericCode"
813	           minOccurs="0" maxOccurs="1" />
814	       </sequence>
815	     </complexType>

817	     <complexType name="resultType" />

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

823	     <complexType name="searchContinuationType">
824	       <sequence>
825	         <element ref="iris:hostReference"
826	           minOccurs="1" maxOccurs="1" />
827	         <element name="registrySearch"
828	           type="iris:registrySearchType"
829	           minOccurs="1" maxOccurs="1"/>
830	       </sequence>
831	     </complexType>

833	     <complexType name="hostReferenceType">
834	       <sequence>
835	         <element name="scheme" type="string"
836	           minOccurs="1" maxOccurs="1" />
837	         <element name="host" type="string"
838	           minOccurs="1" maxOccurs="1" />
839	         <element name="port" type="positiveInteger"
840	           minOccurs="1" maxOccurs="1" />
841	       </sequence>
842	     </complexType>

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

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

850	     <complexType name="serializedEntityURIType">
851	       <simpleContent>
852	         <extension base="iris:entityURIType">
853	           <attribute name="registryID"
854	             type="anyURI" use="required" />
855	           <attribute name="entityClass"
856	             type="iris:entityClassType" use="required" />
857	           <attribute name="entityName"
858	             type="normalizedString" use="required" />
859	           <attribute name="fileName"
860	             type="anyURI" />
861	         </extension>
862	       </simpleContent>
863	     </complexType>

865	     <element name="serializedEntityURI"
866	       type="iris:serializedEntityURIType"
867	       substitutionGroup="iris:entityURI" />

869	     <element name="irisSerialization">
870	       <complexType>
871	         <sequence>
872	           <element ref="iris:result"
873	             minOccurs="1" maxOccurs="unbounded" />

875	         </sequence>
876	       </complexType>
877	     </element>

879	   </schema>

881	7. Internationalization Considerations

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

892	8. IANA Considerations

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

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

907	      urn:ietf:params:xml:ns:iris1

909	9. Security Considerations

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

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

922	References

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

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

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

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

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

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

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

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

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

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

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

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

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

971	   [14]  Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
972	         3023, January 2001.

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

976	Author's Address

978	   Andrew L. Newton
979	   VeriSign, Inc.
980	   21345 Ridgetop Circle
981	   Sterling, VA  20166
982	   USA

984	   Phone: +1 703 948 3382
985	   EMail: anewton@verisignlabs.com
986	   URI:   http://www.verisignlabs.com/

988	Appendix A. Document Terminology

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

994	Appendix B. Acknowledgements

996	   The terminology used in this document to describe namespaces and
997	   namespaces of namespaces is now much clearer thanks to the skillful
998	   debating tactics of Leslie Daigle. Previously, it was much more
999	   confusing.

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

1005	Appendix C. Considerations on XML-based RPC's

1007	   Observations have been made about the similarity between IRIS and
1008	   XML-based RPC mechanisms, specifically SOAP and XML-RPC. And while
1009	   IRIS is not based on a general RPC mechanism, it could easily be
1010	   modeled on top of one, especially SOAP. The use of XML-RPC and SOAP
1011	   has been weighed, and its pay-off has been found to be
1012	   unsatisfactory.

1014	   XML-RPC and SOAP are abstraction layers intended to separate a
1015	   programmer from the details of protocols and to allow the programmer
1016	   to simply use structures and procedures native to a programming
1017	   language (or genericized to only the RPC mechanism). The appeal is
1018	   that the programmer needs to know very little about implementation
1019	   details so that the task of gluing custom logic is inexpensive.
1020	   Supposedly, with little to implement, the job can be done faster or
1021	   easier.

1023	   However, this appeal starts to vanish if the programmer must begin
1024	   to go beyond the native language and familiar tools. And the nature
1025	   of IRIS defined by the CRISP requirements tend to lead an
1026	   implementer down this path. For example, the use of DNS via SRV or
1027	   NAPTR resource records to locate authoritative servers is not
1028	   available in the interfaces of XML-RPC and SOAP.

1030	   Furthermore, XML-RPC and SOAP 1.0 are bound to HTTP. This use, or
1031	   misuse, of HTTP violates RFC 3205. It is possible to put XML-RPC or
1032	   SOAP 1.1 on other application-transports, but the overwhelming
1033	   majority of SOAP and XML-RPC implementations are for HTTP.
1034	   Therefore, chances are that an implementer may have to do this work
1035	   as well.

1037	   In addition, what makes XML-RPC or SOAP much more enticing than
1038	   other similar XML-based mechanisms, such as XMOP or ebXML? And why
1039	   just XML-based solutions? What makes them better than CORBA or DCOM?

1041	   Finally, the intended use of IRIS is more akin to a directory
1042	   service than a remote procedure interface. Basing it on a generic
1043	   mechanism could easily go from lookup( domain ) to register( domain
1044	   ). The latter being clearly out-of-scope for CRISP and rightly in
1045	   the purview of PROVREG.

1047	Full Copyright Statement

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

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

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

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

1075	Acknowledgement

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