view Side-By-Side changes
Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires: December5,29, 2003 June06,30, 2003 IRIS - The Internet Registry Information Service (IRIS) Core Protocoldraft-ietf-crisp-iris-core-02draft-ietf-crisp-iris-core-03 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 December5,29, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes an application layer client-server protocol for a framework of representing the query and result operations of the information services of Internet registries. Specified in XML, the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. Newton Expires December5,29, 2003 [Page 1] Internet-Draft iris-core June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .34 1.1 Use of XML . . . . . . . . . . . . . . . . . . . . . . . . .34 1.2 General Concepts . . . . . . . . . . . . . . . . . . . . . .34 1.3 Framework Layers . . . . . . . . . . . . . . . . . . . . . .45 1.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . .45 1.5Other DocumentsFurther Reading . . . . . . . . . . . . . . . . . . . . . .56 2. Protocol Identification . . . . . . . . . . . . . . . . . .67 3. Exchange Description . . . . . . . . . . . . . . . . . . . .78 3.1 Request Format . . . . . . . . . . . . . . . . . . . . . . .78 3.2 Response Format . . . . . . . . . . . . . . . . . . . . . .79 3.3 Extension Framework . . . . . . . . . . . . . . . . . . . .1011 3.3.1 Derived Elements . . . . . . . . . . . . . . . . . . . . . .1011 3.3.2 Registry Type Identifier Requirements . . . . . . . . . . .1012 3.3.3 Entity Classes . . . . . . . . . . . . . . . . . . . . . . .1113 3.3.4 Names of Entities . . . . . . . . . . . . . . . . . . . . .1214 3.3.5 References to Entities . . . . . . . . . . . . . . . . . . .1214 3.3.6 <result> Derived Elements . . . . . . . . . . . . . . . . .1314 3.3.7 <control> & <reaction> Derived Elements . . . . . . . . . . 16 3.4 Relay Bags . . . . . . . . . . . . . . . . . . . . . . . . .1417 4. Database Serialization . . . . . . . . . . . . . . . . . . .1618 5. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . .1921 6. The IRIS URI . . . . . . . . . . . . . . . . . . . . . . . .2636 6.1 URI Definition . . . . . . . . . . . . . . . . . . . . . . .2636 6.2 Transport Specific Schemes . . . . . . . . . . . . . . . . .2737 6.3 URI Resolution . . . . . . . . . . . . . . . . . . . . . . .2737 6.3.1 Registry Dependent Resolution . . . . . . . . . . . . . . .2737 6.3.2DefaultDirect Resolution . . . . . . . . . . . . . . . . . . . . .2837 6.3.3 Transport & Service Location . . . . . . . . . . . . . . . .2938 6.4 IRIS URI Examples . . . . . . . . . . . . . . . . . . . . .2938 7. Checklists . . . . . . . . . . . . . . . . . . . . . . . . .3141 7.1 Registry Definition Checklist . . . . . . . . . . . . . . .3141 7.2 Transport Mapping Checklist . . . . . . . . . . . . . . . .3141 8. Internationalization Considerations . . . . . . . . . . . .3242 9. IANA Considerations . . . . . . . . . . . . . . . . . . . .3343 10. Security Considerations . . . . . . . . . . . . . . . . . .3444 References . . . . . . . . . . . . . . . . . . . . . . . . .3545 Author's Address . . . . . . . . . . . . . . . . . . . . . .3747 A. NAPSTR and IRIS Uses . . . . . . . . . . . . . . . . . . . .3848 A.1 An Examples of NAPSTR with IRIS . . . . . . . . . . . . . .3848 A.2 Using NAPSTR for Cohabitation . . . . . . . . . . . . . . .3949 B. Document Terminology . . . . . . . . . . . . . . . . . . . .4151 C.AcknowledgementsIRIS Design Philosophy . . . . . . . . . . . . . . . . . . . 52 C.1 The Basic Premise . . . .42. . . . . . . . . . . . . . . . . 52 C.2 The Lure of a Universal Client . . . . . . . . . . . . . . . 53 C.3 Server Considerations . . . . . . . . . . . . . . . . . . . 53 C.4 Lookups, Searches, and Entity Classes . . . . . . . . . . . 54 Newton Expires December 29, 2003 [Page 2] Internet-Draft iris-core June 2003 C.5 Entities References, Search Continuations, and Scope . . . . 54 D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . .4357 Newton Expires December5,29, 2003 [Page2]3] Internet-Draft iris-core June 2003 1. Introduction The specification outlined in this document is based on the functional requirements described in CRISP [1]. 1.1 Use of XML This document describes the specification for the Internet Registry Information Service (IRIS), an XML text protocol with the purpose of describing the query types and result types of various registry information services. IRIS is specified using the Extensible Markup Language (XML) 1.0 as described in [5], XML Schema notation as described in [7] and [8], and XML Namespaces as described in [6]. 1.2 General Concepts Each kind of Internet registry is identified by a registry type. The identifier for a registry type is a URI, more specifically a URN, used within the XML instances to identify the XML schema formally describing the set of queries, results, and entity classes allowed within that type of registry. The structure of these URN's makes no assumptions or restrictions on the type of registries they identify. Therefore, IRIS may support multiple registry types of disparate or similar nature; it is only a matter of definition. For instance, a single registry type may be defined for domain name registries while multiple registry types may be defined for the various IP address registries. A registry information server may handle queries and serve results for multiple registry types. Each registry type that a particular registry operator serves is a registry service instance. IRIS and the XML schema formally describing IRIS do not specify any registry, registry identifier, or knowledge of a particular service instance or set of instances. IRIS is a specification for a framework with which these registries can be defined, used, and in some cases interoperate. The framework merely specifies the elements for registry identification and the elements which must be used to derive queries and results. This framework allows a registry type to define its own structure for naming, entities, queries, etc. through the use of XML namespaces and XML schemas (hence, a registry type is identified by the same URI that identifies its XML namespace). In order to be useful, a registry type's specification must extend from this framework. The framework does define certain structures that can be common to Newton Expires December5,29, 2003 [Page3]4] Internet-Draft iris-core June 2003 all registry types, such as references to entities, search continuations, entity classes, and more. A registry type may declare its own definitions for all of these, or it may mix its derived definitions with the base definitions. IRIS defines two types of referrals, an entity reference and a search continuation. An entity reference indicates specific knowledge about an individual entity, and a search continuation allows for distributed searches. Both referrals may span differing registry types and instances. No assumptions or specifications are made about roots, bases, or meshes of entities. 1.3 Framework Layers The IRIS framework can conceptually be thought of as having three layers. ---------------------------- Registry-Specific |domain | address |routing|etc... | ---------------------------- Common-Registry | IRIS | ---------------------------- Application-Transport | beep | ---------------------------- The differing layers have the following responsibilities: Registry-Specific :: Defines queries, results, and entity classes of a specific type of registry. Each specific type of registry is identified by a URN. Common-Registry :: Defines base operations and semantics common to all registry types such as referrals, entity references, etc. It also defines the syntaxes for talking about specific registry types. Application-Transport :: Defines the mechanisms for authentication, message passing, connection and session management, etc. It also defines the URI syntax specific to the application-transport mechanism. However, because of the separation of the layers, other transports can and have been defined ( iris-lwz [18] ). 1.4 Definitions For clarity, the following definitions are supplied: Newton Expires December5,29, 2003 [Page4]5] Internet-Draft iris-core June 2003 o registry type - A registry serving a specific function, such as a domain registry or an address registry. Each type of registry is assigned a URN. o registry schema - The definition for a registry type specifying the queries, results, and entity classes. o authority - A reference to the server or set of server containing information. o resolution method - The method used to resolve an authority. o entity class - A group of entities with a common type or common set of characteristics. o entity name - The identifier used to refer to a single entity within an entity class. o entity reference - A pointer to an entity composed of an authority, an optional resolution method, a registry type, an entity class, and an entity name. One type of entity reference is the IRIS URI (defined in Section 6 ). The terms "derivative", "derive", and "derivation" are used with the same meaning for deriving one type of element from another as specified in XML_SS [8]. 1.5Other DocumentsFurther Reading Appendix C contains text answering the question, "Why IRIS?" This document describes the structure at the core of IRIS. The following documents describe the other aspects of IRIS relevant to CRISP [1]: iris-beep [2], and iris-dreg [3]. The following documents describe aspects of IRIS that are not directly relevant to CRISP but demonstrate the flexibility and extensibility of IRIS: iris-areg [4], iris-lwz [18], and iris-credreg [19]. Newton Expires December5,29, 2003 [Page5]6] Internet-Draft iris-core June 2003 2. Protocol Identification The root element of all request XML instances MUST be <request>. The root element of all response XML instances MUST be <response>. These elements identify the start of the IRIS elements, the XML namespace used as the identifier for IRIS, and the location of the schema. These elements and the associated closing tag MUST be applied to all requests and responses sent by both clients and servers. An abstracted example: <request xmlns="urn:ietf:params:xml:ns:iris1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd"> </request> Figure 2 The use of the schema location URI in the <xsi:schemaLocation> element is OPTIONAL with respect to its use by this specification, and IRIS implementations MAY resolve it to retrieve the schema or they MAY use a locally cached version of the schema. The presence of this URI is mandatory according to [8]. The URI MUST be a validURI, and SHOULD resolve if the appropriate network resources are available.URI. Versioning of the IRIS protocol is the responsibility of the application-transport layer but MUST be associated with the XML namespace [6] URI representing IRIS. A change in this URI indicates a change of the underlying schema and therefore a new version of the protocol. Newton Expires December5,29, 2003 [Page6]7] Internet-Draft iris-core June 2003 3. Exchange Description This section describes the request and response exchanges of the protocol. The descriptions contained within this section refer to XML elements and attributes and their relation to the exchange of data within the protocol. These descriptions also contain specifications outside the scope of the formal XML syntax. Therefore, this section will use terms defined by RFC 2119 [15] to describe the specification outside the scope of the formal XML syntax. While reading this section, please reference Section 5 for needed details on the formal XML syntax.3.1 Request FormatA<request> element contains <searchSet> elements. These <searchSet> elements enables aclientto querymay either send aparticular registry type using the URN identifying the registy type. This can be found in oneset ofit's two children: <lookupEntity> and <query>. Thesearches in a request or a control. A server responds to a set of searches with a set of results, and a server responds to a control with a reaction. The following is a simple summary: client ------(searches)------> server client <-----(results)-------- server or client ------(control)-------> server client <-----(reaction)------- server 3.1 Request Format A <request> element contains either <searchSet> elements or a <control> element. The <searchSet> elements enables a client to query a particular registry type using the URN identifying the registry type. This can be found in one of it's two children: <lookupEntity> and <query>. The <lookupEntity> element describes the lookup of an entity in a specific registry. This element has three attributes: 'registryType', 'entityClass', and 'entityName'. The 'registryType' attribute contains the registry identifier for the registry type in which the lookup operation is to take place. The 'entityClass' attribute contains the token identifying the index for which the Newton Expires December 29, 2003 [Page 8] Internet-Draft iris-core June 2003 lookup operation is to take place, and the 'entityName' attribute contains the name of the entity to lookup. The <query> element is abstract and may not legally appear in an XML instance. It provides the base type to be used by registry schemas to define derived query types. This derivation mechanism is described in Section 3.3. Each <searchSet> may also contain a <bag> element. When this element appears as a child of <searchSet>, it MUST NOT contain the 'id' attribute. For a description of the <bag> element, see Section 3.4. The <control> element is a base type. Its derivatives allow a client to signal to a server the desire for special states or processing. 3.2 Response Format The <response> element contains either <resultSet>elements. Theseelements or a <reaction> element. The <resultSet> elements are responses to a <searchSet> request. The contents of this element contain an <answer> element, an optional <additional> element, an optional <bags> element, and error elements if applicable. The children of the <answer> element are of the following types: o <result> is an abstract element and may not be legally placed inNewton Expires December 5, 2003 [Page 7] Internet-Draft iris-core June 2003an XML instance. It provides the base type to be used by registry schemas to define derived result types. This derivation mechanism is described in Section 3.3. o <entity> is an element specifying an entity reference. It has the following attributes to refer to the entity: 'authority', 'resolution', 'registryType', 'entityClass', and 'entityName'. It also may have a <displayName> child element. This child element specifies a human-friendly name (and appropriate language via its 'language' attribute) so the clients may present this entity reference to a user in a friendlier fashion. The <entity> element may also have a 'bagRef' attribute. If present, this attribute must contain an XML identifier to a <bag> element in the <bags> section of the result set. For a description of the 'bagRef' attribute, see Section 3.4. o The <searchContinuation> element children contains an <authority> element, an optional <resolution> element and a <query> element. The <authority>element indicatesand <resolution> elements indicate where the search continuation should be directed, and the <query> element is Newton Expires December 29, 2003 [Page 9] Internet-Draft iris-core June 2003 the query to be conducted. The <searchContinuation> element may also contain a 'bagRef' attribute, and has the same meaning and purpose as specified with the <entity> element. For a description of the 'bagRef' attribute, see Section 3.4. The <searchContinuation> element may also have the attributes 'authority', 'resolution', 'registryType', 'entityClass', and 'entityName'. These attributes are provided to give the search continuation context, especially for the purposes of database serialization (Section 4). When following entity references and search continuations, clients SHOULD only follow an <entity> or <searchContinuation> response once. Failure to do so may result in the client process getting stuck in a never-ending query loop commonly known as a referral loop. The <additional> element only contains <result> elements, as described above. This element is provided to allow a server to indicate to a client results that were not specifically queried but are related to the queried results, thus allowing the client the ability to properly display this distinction to a user. The <additional> element use is optional. The <bags> element is optional. It contains <bag> elements, and the contents of each <bag> element is unspecified by IRIS. Each <bag> element has an 'id' attribute, which is referenced by the 'bagRef' attribute of entity references (<entity>) and search continuations (<searchContinuation>). See Section 3.4. The following elements, representing error conditions, may beNewton Expires December 5, 2003 [Page 8] Internet-Draft iris-core June 2003returned: o <insufficientResources> - the corresponding query requires resources unobtainable by the server. o <invalidName> - a name given in a query is not syntactically correct. o <invalidSearch> - parameters of the corresponding query are not semantically meaningful. o <limitExceeded> - the corresponding query requires more resources than allowed. o <nameNotFound> - the name given in a query does not match a known entity. o <permissionDenied> - the authentication given does not allow access to a specific result entry. Newton Expires December 29, 2003 [Page 10] Internet-Draft iris-core June 2003 o <bagUnrecognized> - the contents of a bag were unrecongnized. See Section 3.4. o <bagUnacceptable> - the contents of a bag were not and never will be acceptable. See Section 3.4. o <bagRefused> - the contents of a bag were not acceptable at this time. See Section 3.4. o A derivative of <genericCode>, as described in Section 3.3. The <resultSet> section is divided up into the <answer> and <additional> sections in order to allow easier processing and navigation of the results by a client. Servers MUST return the direct answers to queries in the <answer> element, and MAY return results in the <additional> element for which a reference has been made to in the <answer> element. Results in the <additional> element MUST have been referenced in the <answer> either as direct children of the <answer> element or as a deeper descendant of the <answer> element. This serves two purposes. First, it may eliminate a requery by the client for references contained in the <answer> element. Second, it distinguishes between results that are a direct result of a query and those that would have been returned had the client followed the appropriate referrals, thus giving clients a hint as to how to process or display the returned results. For instance, clients constructing complex displays using tree navigation widgets will knowNewton Expires December 5, 2003 [Page 9] Internet-Draft iris-core June 2003that results in the <answer> element should all be directly beneath the root node of the tree, while results in the <additional> element are to be leaf nodes of those produced from the <answer> element. A <reaction> element is a response to a <control> element, and provide a means for a server to advise a client of the affect of a <control> element. 3.3 Extension Framework Because the IRIS schema defines only one query type, no registry structure, and only two stand-alone result types, it is of limited use by itself. Extension of IRIS is accomplished through the use a base IRIS schema, as defined in XML_SD [7] and XML_SS [8], and extension of it by schemas constructed on top of IRIS. 3.3.1 Derived Elements The XML Schema definition of IRIS requires schemas of registry types to derive element types from base types in the IRIS definition. The registry schemas MUST derive elements for definition of typed queries Newton Expires December 29, 2003 [Page 11] Internet-Draft iris-core June 2003 and results. While the IRIS schema definition does not prohibit the derivation of any elements, registry schemas SHOULD restrict the derivations to the following types: o <query> - as defined this element contains no content and has no valid attributes. It is abstract and therefore only derivatives of it appear in XML instances. Registry schemas derive from this element to define the queries allowed. o <result> - as defined this element contains no content and hasfourfive valid attributes: 'authority', 'resolution' (optional), 'registryType', 'entityClass' and 'entityName'. It is abstract and therefore only derivatives of it appear in XML instances. Registry schemas derive from this element to define results that may be returned from a query. o <control> - same as <query>. o <reaction> - same as <query>. o <genericCode> - as defined, this element is an instance of <codeType>. It contains the optional elements <explanation> and <language> to further describe the nature of the error. o <seeAlso> - contains one or more <entity> elements. This element indicates one or more references to entities that have indirect association with a parent element representing an entity. Registry schemas MAY derive from this element or MAY use it directly. 3.3.2 Registry Type Identifier Requirements The identifier for a registry type and the XML namespace identifierNewton Expires December 5, 2003 [Page 10] Internet-Draft iris-core June 2003used by the XML Schema describing the registry MUST be the same. These identifiers MUST be restricted to any valid URN[11].[11] in compliance with XML_URN [16]. This is a restriction on XML_NS [6], which specifies an XML namespace identifier is any valid URI [10].When possible, registry identifiers SHOULD be URN's defined by XML_URN [16].Because these URN's represent namespace identifiers which are to be used in XML documents for the purposes of XML namespaces as specified by XML_NS [6], they MUST be of the class "ns" as defined in XML_URN [16].Case sensitivity of registry ID's is dependent on the namespace definition of the URN itself.RegistryID'sURN's conforming to XML_URN [16] are case insensitive.When registry identifiers areRegistry URN'sdefined by XML_URN [16] and the class component is "ns", theyMAY be abbreviated to the part following the class Newton Expires December 29, 2003 [Page 12] Internet-Draft iris-core June 2003 component and its separator of the URN. For example, the full URN "urn:ietf:params:xml:ns:dreg1" may be abbreviated to"dreg1", but the full URN "urn:otherOrg:ns:myreg1" cannot be abbreviated."dreg1". This abbreviation MUST NOT be used inside of XML instances in use with IRIS where XML Schema [7] specifies the use of a URI for schema identification or where XML_NS [6] specifies the use of a URI for XML namespace identification. 3.3.3 Entity Classes Entity classes are provided in IRIS to help avoid collisions with entity names with in any given registry type. Their specification in queries also allows server implementations to quickly narrow search or lookup scopes to a single index. For instance, the entity name "10.0.1.0" would refer to separate entities in the "name-server" and "network" classes. The entity "10.0.1.0" in the "nameServer" class may refer to the name server host that is also multi-homed by address 192.178.0.1 and known in DNS as "ns.foo.com", whereas the entity "10.0.1.0" in the "network" class may refer to the network 10.0.1/24. IRIS defines two default entity classes of "named-query" and "service-definition" which MAY NOT be redefined. These entity classes MUST be valid in all registry types. The "named-query" class is for the naming of canned queries by registries. Therefore an entity lookup of a canned query MAY resultNewton Expires December 5, 2003 [Page 11] Internet-Draft iris-core June 2003in a search continuation on the same registry or a set of predefined results. When used in URI's, this is a type of boot-strapping procedure. Therefore, the resolution of"iris:com/dreg1/named-query/"iris:dreg1//com/named-query/ registrars" may result in the list of registrars currently registering domains. The set of named queries are not specified by IRIS. The "service-definition" class is reserved for entities specific to a particular service instance. It MUST containanthe following entitynamed "id"names (see Section3.3.43.3.4: o "id" which yields a result of <serviceIdentification> (see Section3.3.6.1.3.3.6.1). o "limits" which yields a result of <limits> (see Section 3.3.6.2 ). This entity class MAY contain other locally defined entities as well. The names of entity classes in a registry schema are of type token defined by XML_SD [7]. Their use SHOULD be transcribable. Their case Newton Expires December 29, 2003 [Page 13] Internet-Draft iris-core June 2003 sensitivity MUST be defined by the definition of the registry type. In general, they SHOULD be case insensitive. 3.3.4 Names of Entities The names of entities in a registry schema are of type token defined by XML_SD [7]. Their use SHOULD be transcribable. Names of entities SHOULD be unique within an instance of any particular entity class within a registry. Two entities SHOULD NOT have the same name, but a single entity MAY be known by multiple names. In situations where a single name may result in two entities, the registry schema SHOULD make allowances by defining result types that contain entity references to both entities (i.e. "foo.com" can refer to both the domain foo.com and the host foo.com). However, this type of conflict SHOULD generally be avoided by the proper use of entity classes. When specifying elements that represent entities, registry schemas must attach the attributes 'authority', 'resolution' (optional), 'registryType', 'entityClass', and 'entityName'. This aids clients in understanding which parts of a result set represent an entity. The case sensitivity of entity names is dependent on the entity class in which they reside. The definition of a registry type MUST specify the case sensitivity for entity names. A registry type MAY define the entity names of differing entity classes to have different case sensitivity. However, a registry type SHOULD be consistent with case sensitivity and SHOULD specify case insensitivity if possible. 3.3.5 References to Entities The element <entity> allows references to entities in result sets,Newton Expires December 5, 2003 [Page 12] Internet-Draft iris-core June 2003either as a direct child of <resultSet> or within a more complex structure that derives from <result>. Registry schemas MUST NOT derive elements from this element so that clients will have a better understanding of what is and what isn't an entity reference. This is especially useful to clients when dealing with XML conversion technologies such as XPath. The <entity> element can have a child element of <displayName> with an optional 'language' attribute. These are provided so that servers may provide to clients a more human friendly meaning to the entity reference. This is often useful to users navigating referral structures. 3.3.6 <result> Derived Elements Newton Expires December 29, 2003 [Page 14] Internet-Draft iris-core June 2003 The base IRIS framework does containtwothree elements directly derived from the <result> element for use by any registry type. 3.3.6.1 <serviceIdentification> The <serviceIdentification> element is provided to allow IRIS clients the ability to reference IRIS service instances. It contains the following elements: o <authorities> - This element contains one or more <authority> elements. Each <authority> element contains a URI authority component for which the server has results. While a server MAY only return a partial list of its authority areas depending on operator policy, it MUST return the authority for which the client has requested. o <eMail> - This optional element contains an email address of the operator of the service instance. o <phone> - This optional element contains the phone number of the operator of the service instance. o<limits> - This optional element describes the limits of service a client will experience when querying this server. o<seeAlso> - See Section 3.3.1 for its definition. 3.3.6.2 <limits> Thecontents of the<limits> elementare as follows: o <accessLevel> - This element is required and indicatesprovides a mechanism totheallow a server to inform a clientat which access levelof thedescribedlimitsare active. To do this,it may encounter from over use of theelement has two required boolean attributes: 'atCurrentLevel' and 'atAnonymousLevel'. Ifservice. The contents describe thelimits described Newton Expires December 5, 2003 [Page 13] Internet-Draft iris-core June 2003 by siblings of this element apply whenservice limitations to auser is authenticatedclient at the currentaccesslevelused to conduct this query, then the 'atCurrentLevel' attribute should be true. If the limits described by siblingsof access. The contents of this elementapply when a user has given no authentication information or is considered to be anonymous, then the 'atAnonymousLevel' attribute should be true.are as follows: o <totalQueries> - This element describes the total number of queries that the server willaccept at the indicated access level.accept. The children of this element indicate this number per a unit of time. The children are <perSecond>, <perMinute>, <perHour>, and <perDay>. Each child MUST only appear once as a child of <totalQueries>, but more than one child MAY be present. For example, a server could indicate that it will accept 15 queries a minute but only 60 queries a day. o <totalResults> - This element describes the total number of results that the server will send to a clientat the indicated access level.The children of this element indicate this number per a unit of time in the same manner as <totalQueries>.3.3.6.2 <simpleEntity> The <simpleEntity>o <totalConnections> - This elementis provided sodescribes the total number of connections thatservice operators may make simplethe server will accept from a client The children of this element indicate this number per a unit of time in the Newton Expires December 29, 2003 [Page 15] Internet-Draft iris-core June 2003 same manner as <totalQueries>. 3.3.6.3 <simpleEntity> The <simpleEntity> element is provided so that service operators may make simple additions to other entities without the need for deriving entirely new registry types. Its definition allows service operators to make it a referent from other entities (using, for instance, a <seeAlso> element). The <simpleEntity> is meant to represent name and value pairs of strings, allowing each pair to be associated with a specific languagequalifier.qualifier, and optional URI pointing to more information. Clients may easily display such information as a two-column table. Uses needing binary data or richer data structures are out of scope for this element. When such usage scenarios arise, it is likely that a client will need specific knowledge for handling such data thus calling into question the need for a new registry type. 3.3.7 <control> & <reaction> Derived Elements When a client sends an <onlyCheckPermissions> control, it is asking the server to enter a state where queries are only checked for their permission. This element can have one of two children: o <start> - starts the only-check-permissions state. o <stop> - stops the only-check-permissions state. A server MUST respond to this control with a <standardReaction> element. The <standardReaction> element provides a server with a standard means to respond to controls. It contains three children: o <controlAccepted> - the processing or state needed by the control has been accepted. o <controlDenied> - the processing or state needed by the control has been denied (a transient failure). o <controlDisabled> - the processing or state needed by the control cannot be activated (a permanent failure). Newton Expires December 29, 2003 [Page 16] Internet-Draft iris-core June 2003 3.4 Relay Bags IRIS employs the use of bags to allow a server to relay information to areferantreferent server via the client. The contents of the bags are not defined by IRIS, and the client MUST NOT make any assumptions about the contents of a bag when relaying it from one server to another. When a server returns a result set from a client, the <resultSet> element may contain a <bags> child element. This child element contains one or more <bag> elements. Each of these MUST contain anNewton Expires December 5, 2003 [Page 14] Internet-Draft iris-core June 2003'id' attribute containing the XML datatype ID. Entity references and search continuations that need to specify a bag to be used when they are followed MUST have a 'bagRef' attribute containing the XML datatype IDREF. See Section 3.2. This allows the result set to only specify a bag once but allow each entity reference or search continuation to have a distinct bag as needed. When following an entity reference or search continuation that specifies the use of a bag, the client must include therefencedreferenced bag in the search set as the latter child of the <searchSet> element. See Section 3.1. See Section 3.2 for the list of errors a server may return to a client when a bag is received. Newton Expires December5,29, 2003 [Page15]17] Internet-Draft iris-core June 2003 4. Database Serialization This section describes a method for serializing IRIS registry entities. The descriptions contained within this section refer to XML elements and attributes and their relation to this serialization process. These descriptions also contain specifications outside the scope of the formal XML syntax. Therefore, this section will use terms defined by RFC 2119 [15] to describe the specification outside the scope of the formal XML syntax. While reading this section, please reference Section 5 for needed details on the formal XML syntax. A database of IRIS entities can be serialized to file storage with XML [5] using the IRIS defined <serialization> element. This element contains <result> element derivatives, <searchContinuation> elements, and <serializedNamedQuery> elements. Derivatives of the <result> element are entities. Servers loading these entities MUST place the entity in the entity class specified by the elements 'registryType', 'entityClass', and 'entityName' attributes and any entity class which the entity may apply according to explicitly defined children of that element. For instance, if a registry type has two entity classes of "foo" and "bar" and a <result> derivative has the attributes entityClass="foo" and entityName="one" and a child element <bar>two</bar>, the server is to enter that entity into the entity class "foo" as the name "one" and the entity class "bar" as the name "two". Servers loading entities as serialized derivatives of the <result> element MAY translate the authority attribute. Servers will likely need to do this if the authority for the entity has changed. <searchContinuation> elements allow for the serialization of static referrals. When this element appears as a child of the <serialization> element, it MUST have the 'authority', 'registryType', 'entityClass', and 'entityName' attributes. <serializedNamedQuery> element allows for the specification of static results for a named query. This element contains a <resultSet> element holding the results to be returned by the server if the named query is requested. The server MUST place the named query in the "named-query" entity class. As mentioned above, there may be times when a server needs to translate the authority attribute of a loaded entity. The <serializedEntity> element is provided for conditions where this must also be done for entity references. During deserialization, servers MAY change the authority attribute of the <serializedEntity> element Newton Expires December5,29, 2003 [Page16]18] Internet-Draft iris-core June 2003 to be an authority for which the server answers queries. During serialization, servers and their related processes MUST use the <serializedEntity> element instead of the <entity> element for entity references in which the referent of the URI is an entity for which the server answers queries. The authority attribute of the <entity> element SHOULD NOT be altered during serialization or deserialization. The following is an example of serialized IRIS. <iris:serialization xmlns:iris="urn:ietf:params:xml:ns:iris1" xmlns="urn:ietf:params:xml:ns:iris1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > <serviceIdentification authority="com" registryType="dreg1" entityClass="service-definition" entityName="id" > <authorities> <authority> com </authority> <authority> net </authority> </authorities> <eMail> davidb@verisignlabs.com </eMail><limits> <accessLevel atCurrentLevel="true" atAnonymousLevel="false" /> <totalQueries> <perDay>15</perDay> </totalQueries> <totalResults> <perDay>100</perDay> </totalResults> </limits><seeAlso> <entity authority="com" registryType="dreg1" entityClass="service-definition" entityName="notice"> <displayName language="en"> Legal Notice </displayName> </entity> </seeAlso>Newton Expires December 5, 2003 [Page 17] Internet-Draft iris-core June 2003</serviceIdentification> <simpleEntity authority="com" registryType="dreg1" entityClass="service-definition" entityName="notice" > <property name="legal" language="en"> Please use the net wisely! We are required to tell you this. </property> Newton Expires December 29, 2003 [Page 19] Internet-Draft iris-core June 2003 </simpleEntity> </iris:serialization> Newton Expires December5,29, 2003 [Page18]20] Internet-Draft iris-core June 2003 5. Formal XML Syntax IRIS is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of IRIS suitable for automated validation of IRIS XML instances. <?xml version="1.0"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:iris="urn:ietf:params:xml:ns:iris1" targetNamespace="urn:ietf:params:xml:ns:iris1" elementFormDefault="qualified" > <annotation> <documentation> Internet Registry Information Service (IRIS) Schema v1 </documentation> </annotation> <!-- ========================================= --> <!-- --> <!-- The Transactions --> <!-- --> <!-- ========================================= --> <element name="request"> <complexType> <choice> <sequence> <element name="searchSet" type="iris:searchSetType"minOccurs="0"minOccurs="1" maxOccurs="unbounded" /> </sequence> <element ref="iris:control" /> </choice> </complexType> </element> <element name="response"> <complexType> <choice> <sequence> <element name="resultSet" type="iris:resultSetType"minOccurs="0"Newton Expires December 29, 2003 [Page 21] Internet-Draft iris-core June 2003 minOccurs="1" maxOccurs="unbounded" /> </sequence> <element ref="iris:reaction" /> </choice> </complexType> </element> <!-- ========================================= --> <!-- --> <!-- Search Sets and Result Sets --> <!-- --> <!-- ========================================= --> <complexType name="searchSetType" > <sequence> <choice> <element name="lookupEntity" type="iris:lookupEntityType" /> <element ref="iris:query" /> </choice> <element name="bag" type="iris:bagType" minOccurs="0" maxOccurs="1" /> </sequence> </complexType> <complexType name="resultSetType" > <sequence> <element name="answer" minOccurs="1" maxOccurs="1"> <complexType> <sequence> <element ref="iris:result" minOccurs="0" maxOccurs="unbounded" /> <element ref="iris:entity" Newton Expires December5,29, 2003 [Page19]22] Internet-Draft iris-core June 2003 minOccurs="0" maxOccurs="unbounded" /> <element ref="iris:searchContinuation" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType><complexType name="queryType"/> <element name="query" type="iris:queryType" abstract="true" /> <complexType name="lookupEntityType" > <attribute name="registryType" type="anyURI" use="required" /> <attribute name="entityClass" type="token" use="required" /> <attribute name="entityName" type="token" use="required" /> </complexType> <complexType name="codeType"> <sequence minOccurs="0" maxOccurs="1"> <element name="explanation" type="string" /> <element name="language" type="language" /> </sequence> </complexType> <complexType name="entityType"> <sequence> <element name="displayName" minOccurs="0" maxOccurs="1"> <complexType> <simpleContent> <extension base="string"> <attribute name="language" use="required" type="language" /> </extension> </simpleContent> </complexType> </element> </sequence> <attribute name="authority" use="required" type="token" /> <attribute name="registryType" use="required" type="anyURI" /> <attribute name="entityClass" use="required" type="token" /> <attribute name="entityName" use="required" type="token" /> <attribute name="bagRef" type="IDREF" /> </complexType> <element name="entity" type="iris:entityType" /> Newton Expires December 5, 2003 [Page 20] Internet-Draft iris-core June 2003 <complexType name="seeAlsoType"> <sequence> <element ref="iris:entity" minOccurs="1" maxOccurs="unbounded" /> </sequence> </complexType> <element name="seeAlso" type="iris:seeAlsoType" /> <complexType name="resultSetType" > <sequence> <element name="answer" minOccurs="1" maxOccurs="1"> <complexType> <sequence> <element ref="iris:result" minOccurs="0" maxOccurs="unbounded" /> <element ref="iris:entity" minOccurs="0" maxOccurs="unbounded" /> <element ref="iris:searchContinuation" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType> </element></element> <element name="additional" minOccurs="0" maxOccurs="1"> <complexType> <sequence> <element ref="iris:result" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType> </element> <element name="bags" type="iris:bagsType" minOccurs="0" maxOccurs="1" /> <choice minOccurs="0" maxOccurs="1" > <element name="insufficientResources" type="iris:codeType" /> <element name="invalidName" type="iris:codeType" /> <element name="invalidSearch" type="iris:codeType" /> <element name="limitExceeded" type="iris:codeType" /> <element name="nameNotFound" type="iris:codeType" /> <element name="permissionDenied" type="iris:codeType" /> Newton Expires December5,29, 2003 [Page21]23] Internet-Draft iris-core June 2003type="iris:codeType" /><element name="bagUnrecognized" type="iris:codeType" /> <element name="bagUnacceptable" type="iris:codeType" /> <element name="bagRefused" type="iris:codeType" /> <element ref="iris:genericCode"/> </choice> </sequence> </complexType> <!-- ========================================= --> <!-- --> <!-- Controls and Reactions --> <!-- --> <!-- ========================================= --> <complexTypename="bagsType"> <sequence>name="controlType" /> <elementname="bag" type="iris:bagType" minOccurs="1" maxOccurs="unbounded"name="control" type="iris:controlType" abstract="true" /></sequence> </complexType><complexTypename="bagType" mixed="true"> <sequence> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"name="reactionType"/> <element name="reaction" type="iris:reactionType" abstract="true" /></sequence> <attribute name="id" type="ID"/> </complexType><!-- ========================================= --> <!-- --> <!-- Queries and Lookups --> <!-- --> <!-- ========================================= --> <complexTypename="resultType"> <attribute name="authority" use="required" type="token"name="queryType" /> <element name="query" Newton Expires December 29, 2003 [Page 24] Internet-Draft iris-core June 2003 type="iris:queryType" abstract="true" /> <complexType name="lookupEntityType" > <attribute name="registryType"use="required"type="anyURI" use="required" /> <attribute name="entityClass"use="required"type="token" use="required" /> <attribute name="entityName"use="required"type="token" use="required" /> </complexType><element name="result" type="iris:resultType" abstract="true" /><!-- ========================================= --> <!-- --> <!-- Results --> <!-- --> <!-- ========================================= --> <complexTypename="searchContinuationType"> <sequence> <elementname="resultType"> <attribute name="authority" use="required" type="token"minOccurs="1" maxOccurs="1" /> <element ref="iris:query"/></sequence><attributename="authority"name="resolution" type="token" /> <attribute name="registryType" use="required" type="anyURI" /> <attribute name="entityClass" use="required" type="token" /> <attribute name="entityName" use="required" type="token" /> </complexType> Newton Expires December5,29, 2003 [Page22]25] Internet-Draft iris-core June 2003<attribute name="bagRef" type="IDREF"<element name="result" type="iris:resultType" abstract="true" /></complexType><!-- ========================================= --> <!-- --> <!-- Errors --> <!-- --> <!-- ========================================= --> <complexType name="codeType"> <sequence minOccurs="0" maxOccurs="1"> <elementname="searchContinuation" type="iris:searchContinuationType"name="explanation" type="string" /> <element name="language" type="language" /> </sequence> </complexType> <element name="genericCode" type="iris:codeType" abstract="true" /><element name="serializedEntity" type="iris:entityType" substitutionGroup="iris:entity" /><!-- ========================================= --> <!-- --> <!-- Entity References and --> <!-- Search Continuations --> <!-- --> <!-- ========================================= --> <complexTypename="serializedNamedQueryType">name="entityType"> <sequence> <elementname="resultSet" type="iris:resultSetType" /> </sequence> <attribute name="registryType" type="anyURI" use="required" />name="displayName" minOccurs="0" maxOccurs="1"> <complexType> <simpleContent> <extension base="string"> Newton Expires December 29, 2003 [Page 26] Internet-Draft iris-core June 2003 <attribute name="language" use="required" type="language" /> </extension> </simpleContent> </complexType> </element> </sequence> <attribute name="authority" use="required" type="token" /> <attribute name="resolution" type="token" /> <attribute name="registryType" use="required" type="anyURI" /> <attribute name="entityClass" use="required" type="token"fixed="named-query"/> <attribute name="entityName"type="token"use="required" type="token" /> <attribute name="bagRef" type="IDREF" /> </complexType> <elementname="serialization"> <complexType> <choicename="entity" type="iris:entityType" /> <complexType name="searchContinuationType"> <sequence> <element name="authority" type="token" minOccurs="1"maxOccurs="unbounded">maxOccurs="1" /> <elementref="iris:result"name="resolution" type="token" Newton Expires December 29, 2003 [Page 27] Internet-Draft iris-core June 2003 minOccurs="0" maxOccurs="1" /> <elementref="iris:searchContinuation"ref="iris:query" /> </sequence> <attribute name="authority" type="token" /> <attribute name="resolution" type="token" /> <attribute name="registryType" type="anyURI" /> <attribute name="entityClass" type="token" /> <attribute name="entityName" type="token" /> <attribute name="bagRef" type="IDREF" /> </complexType> <elementname="serializedNamedQuery" type="iris:serializedNamedQueryType"name="searchContinuation" type="iris:searchContinuationType" /></choice><!-- ========================================= --> <!-- --> <!-- Bags --> <!-- --> <!-- ========================================= --> <complexType name="bagsType"> <sequence> <element name="bag" minOccurs="1" maxOccurs="unbounded"> <complexType> <complexContent> <extension base="iris:bagType"> <attribute name="id" type="ID" /> Newton Expires December 29, 2003 [Page 28] Internet-Draft iris-core June 2003 </extension> </complexContent> </complexType> </element> </sequence> </complexType> <complexType name="bagType" mixed="true"> <sequence> <any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType> <!-- ========================================= --> <!-- --> <!-- Derived Results for use with all --> <!-- registry types. --> <!-- --> <!-- ========================================= --> <!-- --> <!-- See Also --> <!-- --> <complexType name="seeAlsoType"> <sequence> <element ref="iris:entity" minOccurs="1" maxOccurs="unbounded" /> </sequence> </complexType> <element name="seeAlso" type="iris:seeAlsoType" /> <!-- --> <!-- Service Identification --> <!-- --> <complexType Newton Expires December 29, 2003 [Page 29] Internet-Draft iris-core June 2003 name="serviceIdentificationType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="authorities" minOccurs="1" maxOccurs="1"> <complexType> <sequence> <element name="authority" type="token" minOccurs="1" maxOccurs="unbounded" />Newton Expires December 5, 2003 [Page 23] Internet-Draft iris-core June 2003</sequence> </complexType> </element> <element name="eMail" type="string" minOccurs="0" maxOccurs="1" /> <element name="phone" type="string" minOccurs="0" maxOccurs="1" /> <elementname="limits"ref="iris:seeAlso" minOccurs="0"maxOccurs="1"> <complexType> <sequence> <element name="accessLevel" minOccurs="1" maxOccurs="1"> <complexType> <attribute name="atCurrentLevel" type="boolean" use="required" /> <attribute name="atAnonymousLevel" type="boolean" use="required"maxOccurs="1" /> </sequence> </extension> </complexContent> </complexType></element><element name="serviceIdentification" type="iris:serviceIdentificationType" substitutionGroup="iris:result" /> <!-- --> <!-- Limits --> <!-- --> <complexType Newton Expires December 29, 2003 [Page 30] Internet-Draft iris-core June 2003 name="limitsType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="totalQueries" minOccurs="0" maxOccurs="1" > <complexType> <group ref="iris:timeLimitsGroup" minOccurs="1" maxOccurs="4" /> </complexType> </element> <element name="totalResults" minOccurs="0" maxOccurs="1" > <complexType> <group ref="iris:timeLimitsGroup" minOccurs="1" maxOccurs="4" /> </complexType> </element></sequence> </complexType> </element><elementref="iris:seeAlso"name="totalConnections" minOccurs="0" maxOccurs="1" > <complexType> <group ref="iris:timeLimitsGroup" minOccurs="1" maxOccurs="4" /> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <elementname="serviceIdentification" type="iris:serviceIdentificationType"name="limits" type="iris:limitsType" substitutionGroup="iris:result" /> Newton Expires December5,29, 2003 [Page24]31] Internet-Draft iris-core June 2003 <group name="timeLimitsGroup"> <choice> <element name="perSecond" type="nonNegativeInteger" /> <element name="perMinute" type="nonNegativeInteger" /> <elementname="perHour "name="perHour" type="nonNegativeInteger" /> <elementname="perDay "name="perDay" type="nonNegativeInteger" /> </choice> </group> <!-- --> <!-- Simple Entity --> <!-- --> <complexType name="simpleEntityType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="property" minOccurs="1" maxOccurs="unbounded"> <complexType> <simpleContent> <extension base="string"> <attribute name="name" type="string" use="required" /> <attribute name="language" type="language" use="required" /> <attribute name="uri" type="anyURI" /> </extension></simpleContent> </complexType> </element>Newton Expires December 29, 2003 [Page 32] Internet-Draft iris-core June 2003 </simpleContent> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <element name="simpleEntity" type="iris:simpleEntityType" substitutionGroup="iris:result" /> <!-- ========================================= --> <!-- --> <!-- Derived Controls and Reactions --> <!-- --> <!-- ========================================= --> <!-- --> <!-- Only Check Permissions --> <!-- --> <complexType name="onlyCheckPermissionsType"> <complexContent> <extension base="iris:controlType"> <choice> <element name="start"> <complexType/> </element> <element name="stop"> <complexType/> </element> </choice> </extension> </complexContent> </complexType> <element name="onlyCheckPermissions" type="iris:onlyCheckPermissionsType" substitutionGroup="iris:control" /> <!-- --> Newton Expires December 29, 2003 [Page 33] Internet-Draft iris-core June 2003 <!-- Standard Reaction --> <!-- --> <complexType name="standardReactionType"> <complexContent> <extension base="iris:reactionType"> <choice> <element name="controlAccepted"> <complexType/> </element> <element name="controlDenied"> <complexType/> </element> <element name="controlDisabled"> <complexType/> </element> </choice> </extension> </complexContent> </complexType> <element name="standardReaction" type="iris:standardReactionType" substitutionGroup="iris:reaction" /> <!-- ========================================= --> <!-- --> <!-- Serialization --> <!-- --> <!-- ========================================= --> <element name="serializedEntity" type="iris:entityType" substitutionGroup="iris:entity" /> <complexType name="serializedNamedQueryType"> <sequence> <element name="resultSet" type="iris:resultSetType" /> Newton Expires December 29, 2003 [Page 34] Internet-Draft iris-core June 2003 </sequence> <attribute name="registryType" type="anyURI" use="required" /> <attribute name="entityClass" type="token" fixed="named-query" /> <attribute name="entityName" type="token" use="required" /> </complexType> <element name="serialization"> <complexType> <choice minOccurs="1" maxOccurs="unbounded"> <element ref="iris:result" /> <element ref="iris:searchContinuation" /> <element name="serializedNamedQuery" type="iris:serializedNamedQueryType" /> </choice> </complexType> </element> </schema> Figure 4 Newton Expires December5,29, 2003 [Page25]35] Internet-Draft iris-core June 2003 6. The IRIS URI The IRIS URI has a very rigid structure but is flexible in how it may be used. Its structure is rigid in that all IRIS URI's have the same fields and all look similar to users. They are flexible because they allow for different methods to be employed to find servers based on the registry type and they allow for the use of multiple transports (with BEEP being the default). 6.1 URI Definition An IRIS URI [10] has the following general syntax.iris:<authority>/<registry-urn>/<entity-class>/<entity-name>iris:<registry>/<resolution>/<authority>/<class>/<name> The full ABNF [20] with certain values included from RFC2396 [10] and RFC2732 [23] follows. iris-uri = scheme+":"authority "/"registry-urn "/" [ resolution-method ] "/" authority [ "/" entity-class "/" entity-name ] scheme = "iris" authority =with-app-svc | without-app-svc with-app-svc = [ userinfo "@" ] hostname [ ";" app-svc ] without-app-svc = [ userinfo "@" ] ( ( host ":" port ) | ipaddress ) [ ";" ] userinfo = // as specified by RFC2396 host = hostname | ipaddress ipaddress = IPv4Address | IPv6Address IPv4Address = // as specified by RFC2396 IPv6Address = // as specified by RFC2732 port =// as specified by RFC2396hostnameregistry-urn = // as specified byRFC2396 app-svcIRIS resolution-method = *(unreserved | escaped)registry-urn = // as specified by IRISentity-class = *(unreserved | escaped) entity-name = *(unreserved | escaped) unreserved = // as specified by RFC2396 escaped = // as specified by RFC2396 An IRIS URI MUST NOT be a relative URI.In addition, valid URI's with this scheme MUST always contain a registry URN (namespace identifier), an entity class, and an entity name. In addition, theThe entity class and entity name MUST be of the UTF-8 [21] character set encoded with "application/x-www-form-urlencoded" as specified by URL_ENC [22].Newton Expires December 5, 2003 [Page 26] Internet-Draft iris-core June 2003When the entity-class and entity-name components are not specified, the defaults "service-definition" and "id" MUST be implied. For example,"iris:com/dreg1""iris:dreg1//com" is to be interpreted"iris:com/dreg1/"iris:dreg1//com/ service-definition/id". When the resolution-method is not specified, the default is the direct resolution method described in Section 6.3.2. Definitions of registry types SHOULD attempt to make the names of entity classes transcribable. Despite the fact that URI's are not friendly to all humans, the care should be taken in their definition to make them readable and transcribable. One aspect of this is the use of dashes to separate meaningful words over the use of other Newton Expires December 29, 2003 [Page 36] Internet-Draft iris-core June 2003 styles such as camel back notation (e.g. "service-definition" instead of "serviceDefinition"). 6.2 Transport Specific Schemes Theoptional app-svc component refers to an application service label. See Section 6.3.3. In all cases it is preceded by a semi-colon (';'), which indicates the use of the default resolution rules (Section 6.3.2). 6.2 Transport Specific Schemes The "iris" scheme name"iris" scheme name is not application transport specific. The URI resolution process MAY determine the application transport. An example of such a process is thedefaultdirect resolution (Section 6.3.2) process, which uses the steps outlined in Section 6.3.3 to determine the application transport. A mapping between an application transport and IRIS MAY define a scheme name signifying its use with the semantics of the IRIS URI. The rules for determining which application transport to use are: o Ifaan application transport specific scheme name is present, the application transport it signifies SHOULD be used if possible. o If a client has a preferred transport and the resolution process allows for its use, the client MAY use that application transport. o Otherwise, the default application transport as specified by IRIS-BEEP [2] MUST be used. 6.3 URI Resolution 6.3.1 Registry Dependent ResolutionThe IRIS URI resolution process can be dependent on the registry type used in the URI itselfInterpretation andkeyed offresolution of theregistry URN that appears in it inauthority component of an IRIS URI may be altered with theabsensespecification of auser override. In other words, the wayresolution-method inNewton Expires December 5, 2003 [Page 27] Internet-Draft iris-core June 2003 whichtheauthorityURI. If no resolution-method componentof the URIisprocessed is dependent onspecified in theregistry type's URN, unlessURI, theuserdefault isspecific abouttheprocess. The rules for determining whichdirect resolutionprocess to use are: o If the authority contains a semi-colon (';') with an application service label, seemethod (see Section6.1, then the default6.3.2). Alternate resolutionprocess defined in Section 6.3.2 is to be used. The application service label to be used is that given after the semi-colon. If none is given, the registry type assigned application service label is tomethods MAY beused. o Otherwise, the resolution processspecified bythe registry type is used. Everyregistrytype MUST specify a resolution processtypes. The identifiers forURI's, even if that specification only defines an application service label and revertsthese methods MUST conform to thedefault process. In all cases, the authority component of the URI MUST be compliant with RFC2396 [10] and RFC2732 [23].ABNF in Section 6.1. 6.3.2DefaultDirect Resolution In thedefaultdirect resolution process, the authority component of an IRIS URI may only contain a domain name, a domain name accompanied by a port number, an IP address, or an IP address accompanied by a port number. The authority component of the scheme indicates the server or set of servers authoritatively responsible for a domain according to records in DNS (Section 6.3.3) if a domain is specified or indicates the specific server to be queried if an IP address is specified. Newton Expires December 29, 2003 [Page 37] Internet-Draft iris-core June 2003 The rules for resolution are: o If the authority component is a domain name accompanied by a port number as specified by RFC2396, the domain name is converted to an IP address via an A or AAAA record to the DNS. o If the authority component is a domain name by itself, the service/transport location (Section 6.3.3) process is used. If this process produces no results, then the DNS is queried for the A or AAAA RRs corresponding to the domain name and the port number used is the well-known port of the transport used according to Section 6.2. o If the authority component is an IP address, then the DNS is not queried, and the IP address is used directly. If the port number is present, it is used directly; otherwise, the port number usedNewton Expires December 5, 2003 [Page 28] Internet-Draft iris-core June 2003is the well-known port of the transport used according to Section 6.2. The use of an IPv6 address in the authority component MUST conform to RFC2732 [23]. 6.3.3 Transport & Service Location Thedefaultdirect resolutionprocessmethod (Section 6.3.2) uses the profiled use of the NAPTR and SRV resource records as defined in NAPSTR [17] to determine both the location of a set of servers for a given service and the set of possible transports that may be used. Anyregistry typeresolution method not deferring to thedefaultdirect resolution process SHOULD use NAPSTR [17] for this purpose. NAPSTR [17] requires an application service label.If this is not specified in the URI (or byThe direct resolution method (Section 6.3.2) uses theuser in some fashion), thenabbreviated form the registry URN as the application servicelabel used is that assigned by the registry type.label. Other resolution methods MAY specify other application service labels. See Appendix A for example uses of NAPSTR. 6.4 IRIS URI Examples Here are some examples of IRIS URI's and their meaning: oiris:example.com/dreg/domain/example.comiris:dreg1//example.com/domain/example.com * Finds a server authoritative for "example.com" according to the rules ofthe registry type "urn:ietf:params:xml:ns:dreg".direct resolution (Section 6.3.2). * The server is asked for "example.com" in the "domain" index, or Newton Expires December 29, 2003 [Page 38] Internet-Draft iris-core June 2003 entity class, of the"dreg""dreg1" registry. oiris:example.com/dregiris:dreg1//example.com * Finds a server authoritative for "example.com" according to the rules ofthe registry type "urn:ietf:params:xml:ns:dreg".direct resolution (Section 6.3.2). * The server is asked for "id" in the "service-definition" index, or entity class, of the"dreg""dreg1" registry. oiris:com/dreg/domain/example.comiris:dreg1//com/domain/example.com * Finds a server authoritative for "com" according to the rules ofthe registry type "urn:ietf:params:xml:ns:dreg".direct-resolution (Section 6.3.2). * The server is asked for "example.com" in the "domain" index, or entity class, of the"dreg""dreg1" registry.Newton Expires December 5, 2003 [Page 29] Internet-Draft iris-core June 2003oiris:10.0.1.1:44/dreg/domain/example.comiris:dreg1//10.0.1.1:44/domain/example.com *Assuming that the registry type "urn:ietf:params:xml:ns:dreg" usesFollowing thedefault resolution process when it encounters IP addresses,rules of direct-resolution (Section 6.3.2), the server at IP address 10.0.1.1 on port 44 is queried using BEEP.The assumption here is that "dreg" means "domain registry" and is therefore not terribly concerned about definitions other than finding authoritative servers for domain names.* The server is asked for "example.com" in the "domain" index, or entity class, of the"dreg""dreg1" registry. oiris-lwz:10.0.1.1:44/dreg/domain/example.comiris-lwz:dreg1//10.0.1.1:44/domain/example.com *Assuming thatFollowing theregistry type "urn:ietf:params:xml:ns:dreg" uses the default resolution process when it encounters IP addresses,rules of direct-resolution (Section 6.3.2), the server at IP address 10.0.1.1 on port 44 is queried using a lightweight application transport. * The server is asked for "example.com" in the "domain" index, or entity class, of the"dreg""dreg1" registry. oiris-beep:com/dreg/domain/example.comiris-beep:dreg1//com/domain/example.com * Finds a server authoritative for "com" according to the rules ofthe registry type "urn:ietf:params:xml:ns:dreg".direct-resolution (Section 6.3.2). * Uses the BEEP application transport. * The server is asked for "example.com" in the "domain" index, or entity class, of the"dreg""dreg1" registry. oiris-beep:example.com;dreg/dreg/domain/example.comiris:dreg1/bottom/example.com/domain/example.com * Finds a server authoritative for"com""example.com" according to thedefaultNewton Expires December 29, 2003 [Page 39] Internet-Draft iris-core June 2003 rules of the resolutionprocess using "dreg" asmethod 'bottom' defined by the registry type urn:ietf:params:xml:ns:dreg1. * The applicationservice label.transport used is determined by the 'bottom' resolution method. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry. o iris-beep:dreg1/bottom/example.com/domain/example.com * Finds a server authoritative for "example.com" according to the rules of the resolution method 'bottom' defined by the registry type urn:ietf:params:xml:ns:dreg1. * Uses the BEEP application transport. * The server is asked for "example.com" in the "domain" index, or entity class, of the"dreg""dreg1" registry. Newton Expires December5,29, 2003 [Page30]40] Internet-Draft iris-core June 2003 7. Checklists 7.1 Registry Definition Checklist Specifications of registry types MUST include the following explicit definitions: o Formal XML syntax deriving from the IRIS XML. o An identifying registry URN. oURIAny registry specific resolutionscheme -methods. o Adefinition of the processregistration ofresolvingtheauthority ofabbreviated registry URN as anIRIS URI or a declaration to use the default authority resolution scheme in Section 6.3.2. o Anapplication service label for compliance with NAPSTR [17].See Section 6.3.3.Note, this is a different IANA registry than the registry type URN IANAregistry, however, using the abbreviated (Section 3.3.2) form of the registry URN as the application service label is good practice. o A listregistry. o A list of well-known entity classes. o A statement regarding the case sensitivity of the names in each entity class. 7.2 Transport Mapping Checklist Specifications of transport mappings MUST include the following explicit definitions: o A URI scheme name specific to the transport. o An application protocol label for compliance with NAPSTR [17]. See Section 6.3.3. Note, this is a different IANA registry than the scheme name IANA registry, however, there is nothing stopping them from being the same string of characters. Newton Expires December5,29, 2003 [Page31]41] Internet-Draft iris-core June 2003 8. 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 [25] and [12]. The application-transport layer MUST define a common set of character set encodings to be understood by both client and server. Localization of internationalized strings may require additional information by the client. Entity definitions SHOULD use the "language" type defined by XML_SD [7] to aid clients in the localization process. See Section3.3.6.23.3.6.3 as an example. Newton Expires December5,29, 2003 [Page32]42] Internet-Draft iris-core June 2003 9. 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 [13], URI assignment requests SHOULD be reviewed by a designated expert, and values SHOULD be assigned only as a result of standards action taken by the IESG. This document makes use of a proposed XML namespace and schema registry specified in XML_URN [16]. Accordingly, the following URN will need to be registered with IANA: urn:ietf:params:xml:ns:iris1 Newton Expires December5,29, 2003 [Page33]43] Internet-Draft iris-core June 2003 10. Security Considerations IRIS provides no authentication or privacy facilities of its own. It relies on the application-transport layer for all of these abilities. Implementers need to fully understand the application-transports employed by IRIS. Referral IRIS registry results may contain entity lookups and search continuations which result in a client query operation against another registry service. The authentication credentials and mechanisms subject to replay attacks SHOULD NOT be used to conduct a subsequent entity lookup or search continuation. Newton Expires December5,29, 2003 [Page34]44] Internet-Draft iris-core June 2003 References [1] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", draft-ietf-crisp-requirements-00 (work in progress), August 2002. [2] Newton, A., "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", draft-ietf-crisp-iris-beep-01 (work in progress), October 2002. [3] Newton, A., "IRIS Domain Registry Schema", draft-ietf-crisp-iris-dreg-01 (work in progress), October 2002. [4] Newton, A., "IRIS Address Registry Schema", draft-ietf-crisp-iris-areg-01 (work in progress), October 2002. [5] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/ REC-xml-19980210>. [6] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, <http://www.w3.org/TR/1999/ REC-xml-names-19990114>. [7] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/ REC-xmlschema-2-20010502/>. [8] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/ REC-xmlschema-1-20010502/>. [9] World Wide Web Consortium, "Extensible Stylesheet Language (XSL) Version 1.0", W3C XSL, November 2000, <http://www.w3.org/ TR/2000/CR-xsl-20001121/>. [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [11] Moats, R., "URN Syntax", RFC 2141, May 1997. [12] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD 2, October 1994. [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. Newton Expires December5,29, 2003 [Page35]45] Internet-Draft iris-core June 2003 [14] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [16] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-03 (work in progress), November 2001. [17] Daigle, L. and A. Newton, "Domain-based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", draft-daigle-napstr-01 (work in progress), November 2002. [18] Daigle, L. and A. Newton, "Lightweight Internet Registry Information Service", draft-newton-iris-lightweight-00 (work in progress), February 2003. [19] Daigle, L., "IRIS Certificate and Key Registry", draft-daigle-iris-credreg-00 (work in progress), February 2003. [20] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [21] The Unicode Consortium, "The Unicode Standard, Version 2.0", ISBN 0-201-48345-9 ISBN 0-201-48345-9, January 1988, <The Unicode Standard, Version 2.0>. [22] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995. [23] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. [24] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985. [25] <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets> Newton Expires December5,29, 2003 [Page36]46] Internet-Draft iris-core June 2003 Author's Address Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; anewton@ecotroph.net URI: http://www.verisignlabs.com/ Newton Expires December5,29, 2003 [Page37]47] Internet-Draft iris-core June 2003 Appendix A. NAPSTR and IRIS Uses A.1 An Examples of NAPSTR with IRIS This section shows an example use of NAPSTR [17] by IRIS. In this example, there are two registry types: REGA and REGB. There are also two IRIS application transports: iris-a and iris-b. Given this, the use of NAPSTR offers the following: 1. A means to allow an operator to split out the set of servers running REGA from the set of servers running REGB. This is to say, the operator is able to split out the set of servers serving up data for REGA from the set of servers serving up data for REGB. 2. A means to allow an operator to specify which set of servers are running iris-a from the set of servers running iris-b. This is to say, the operator is able to split out the set of servers running protocol iris-a serving REGA and REGB data from the set of servers running protocol iris-b serving REGA and REGB data. 3. A means to allow an operator to specify which set of the servers to operate and which set of the above servers to delegate to another operator. To implement the first feature, the operator deploys the following in their DNS zone: example.com. ;; order pref flags service re replacement IN NAPTR 100 10 "" "REGA:iris-a:iris-b" "" example.com IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" example.com To implement the second feature, the operator then adds the following in their DNS zone:Newton Expires December 5, 2003 [Page 38] Internet-Draft iris-core June 2003example.com. ;; order pref flags service re replacement IN NAPTR 100 10 "s" "REGA:iris-a" "" _iris-a._udp.example.com IN NAPTR 100 10 "s" "REGA:iris-b" "" _iris-b._tcp.example.com _iris-a._udp.example.com. ;; pref weight port target IN SRV 10 0 34 big-a.example.com. IN SRV 20 0 34 small-a.example.com. _iris-b._tcp.example.com. ;; pref weight port target Newton Expires December 29, 2003 [Page 48] Internet-Draft iris-core June 2003 IN SRV 10 0 34 big-b.example.com. IN SRV 20 0 34 small-b.example.com. Finally, an operator may decide to operate the REGA services while delegating the REGB services to somebody else. Here is how that is done: example.com. ;; order pref flags service re replacement IN NAPTR 100 10 "" "REGA:iris-a:iris-b" "" example.com IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" somebodyelse.com Or the operator may decide to operate REGB services under the iris-a protocol/transport while delegating the REGB services under the iris-b protocol/transport to somebody else. example.com. ;; order pref flags service re replacement IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" example.com IN NAPTR 100 10 "s" "REGB:iris-a" "" _iris-a._udp.example.com IN NAPTR 100 10 "s" "REGB:iris-b" "" _iris-b._tcp.somebodyelse.com _iris-a._udp.example.com. ;; pref weight port target IN SRV 10 0 34 big-a.example.com. IN SRV 20 0 34 small-a.example.com. Note that while this last example is possible, it is probably not advisable because of the operational issues involved in synchronizing the data betweenexample.comexample.com and somebodyelse.com. It is provided here as an example of what is possible. A.2 Using NAPSTR for Cohabitation Given the examples in Appendix A.1, the use of NAPSTR could be part of a transition strategy for cohabitation of protocols solving the problems of CRISP [1]. For example, the type of data for domain information could be given the application service label of "DREG1". Given this, the service field of a NAPTR record could read: "DREG1:whois:iris-beep" This service field conveys that domain data, as defined by CRISP, is available both via the iris-beep protocol and the whois protocol. The whois application protocol label refers to RFC 954 [24]. Newton Expires December 29, 2003 [Page 49] Internet-Draft iris-core June 2003 Another example of this would be: "DREG1:iris-beep:ldap" where the data is available via both IRIS and LDAP. Newton Expires December 29, 2003 [Page 50] Internet-Draft iris-core June 2003 Appendix B. Document Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [15]. Newton Expires December 29, 2003 [Page 51] Internet-Draft iris-core June 2003 Appendix C. IRIS Design Philosophy Beyond the concrete arguments that could be placed behind a thoughtful analysis of the bits flying across the ether, there are other abstract reasons for the development of IRIS. This section attempts an explanation. C.1 The Basic Premise IRIS has been designed as a directory service for public-facing registries of Internet resources. The basic premise is this: o A client should be able lookup any single piece of data from any type of registry. This lookup should involve a straight-forward and consistent definition for finding the registry and entail a hit to a single data index in the registry. o Anything more, such as searches up and down the DNS tree to find the registry, searches across multiple indexes in a registry, etc..., requires a client with special knowledge of the data relationships contained within a registry. Therefore IRIS does the following: o It does specify the basic schema language used by all registries to specify their schemas. o It does provide the basic framework for a registry to make a reference to an entity in another type of registry. And, therefore, IRIS does not do the following: o It does not specify a common query language across all types of registries. A common query language imposed across multiple types of registries usually results in the disabling of certain functions by a server operator in order to meet acceptable levels of performance. What this leaves is a common query language that does not commonly work. o It does not impose any relationship between sets of data in any type of registry, such as specifying a tree. There are many types of Internet resources, and they do not all share the same style of relationship with their contained sets of data. An imposition of a common relationship when it is not a natural fit is often a concern and not a benefit. Newton Expires December 29, 2003 [Page 52] Internet-Draft iris-core June 2003 C.2 The Lure of a Universal Client The design premise of IRIS signifies that for directory services there is no such thing as a universal client (or that if there is one, it is commonly called the "web browser"). For IRIS, the closest thing to a universal client is one that may "lookup" data and may be able to display the data in a rudimentary fashion. For a client to be able to "search" data or display it in a truly user-friendly manner, it must have specific knowledge about the type of data it is retrieving. Attempts to outfit a universal client with a common query language are also not very useful. A common query language may be applied to a specific problem domain, requiring a user to have expertise in both the common query language and the problem domain. In the end, the outcome is usually the development of a client specific to the problem domain but saddled with translation of the user's desires and the lowest common denominator aspect of the query language. C.3 Server Considerations As mentioned above, IRIS was designed for the directory service needs of public-facing registries. In this light, there are certain aspects of more generalized directory services that are a hindrance in an environment that does not have the same control and safety considerations of a managed network. For instance, a common query language can provide great flexibility to both the power user and the abusive user. An abusive user could easily submit a query across multiple indexes with partial values. Such a query would have no other utility than to cause denial of service to other users. To combat this, a service operator must restrict the types of queries that cause harm to overall performance, and this act obsoletes the benefit of a common query language. Another consideration for server performance is the lack of a required data relationship. Because sets of data often have differing relationships, a one-size-fits-all approach does not fit well with all types of registries. In addition, public-facing services tend to have service level requirements that cannot reasonably be met by transforming complete data stores from a native format to that of a format enforcing an artificial set of relationships. To combat these issues, operators of public-facing services tend to create their own custom query parsers and back-end data stores. But doing so brings into question the use of a generalized directory Newton Expires December 29, 2003 [Page 53] Internet-Draft iris-core June 2003 service. Finally, IRIS is built upon a set of standard technological layers. This allows service operators the ability to switch in and out components to meet the needs of their particular environment. C.4 Lookups, Searches, and Entity Classes IRIS supports both lookups and searches. Conceptually, the difference between the two is as follows: A "lookup" is a single query with a discrete value on a single index. Anything more, such as a partial value queries, queries across multiple indexes, or multiple queries to a single index, is a "search". Lookups are accomplished through the use of the defined query <lookupEntity>. This query specifies a discrete name, called the entity name, to be queried in a single index, called the entity class. Therefore, implementations may consider a type of registry to be composed of multiple indexes, one for each defined entity class. There are no standard searches in IRIS. Each type of registry defines its own set of searches. C.5 Entities References, Search Continuations, and Scope Due to its importance in client behavior and the side effects such behavior may have on servers, IRIS makes a clear distinction between entity references (<entity>) andsomebodyelse.com.search continuations (<searchContinuation>). It isprovided here asnot anexampleadd-on, but a fundamental core ofwhat is possible. A.2 Using NAPSTR for Cohabitation Giventheexamples in Appendix A.1,protocol. The distinction is very important to a client: "Go look over there and you will find what you seek." "Go look over there and you may find what you seek, or you may find some other stuff, or you may find nothing." Finally, because IRIS makes no assumptions and places no requirements on theuse of NAPSTR could be partrelationship of data in atransition strategy for cohabitation of protocols solving the Newton Expires December 5, 2003 [Page 39] Internet-Draft iris-core June 2003 problemsregistry, this also extends to data ofCRISP [1]. For example,the same registry type spread across multiple authority areas. This means that IRIS makes no requirements with regard to scope ofdata for domain information could be given the application service label of "CRISP-DOMAIN". Given this, the service fieldentity references or search continuations. The definition of scope is strictly aNAPTR record could read: "CRISP-DOMAIN:whois:iris-beep" This service field conveys that domain data, as definedfunction of need byCRISP, is available both via the iris-beep protocol andthewhois protocol. The whois application protocol label refers to RFC 954 [24]. Another exampletype ofthis would be: "CRISP-DOMAIN:iris-beep:ldap" where the data is available via both IRISregistry andLDAP.the Newton Expires December5,29, 2003 [Page40]54] Internet-Draft iris-core June 2003Appendix B. Document Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [15].allowances given a service operator by that type of registry. Newton Expires December5,29, 2003 [Page41]55] Internet-Draft iris-core June 2003 AppendixC. AcknowledgementsD. Acknowledgments The terminology used in this document to describe namespaces and namespaces of namespaces is now much clearer thanks to the skillful debating tactics of Leslie Daigle. Previously, it was much more confusing. In addition, Leslie has provided great insight into the details of URI's, URN's, and NAPTR/SRV resource records. Many other technical complexities were proved to be unnecessary by David Blacka and have been removed. And his IRIS implementation has helped smooth out the rougher edges. Newton Expires December5,29, 2003 [Page42]56] Internet-Draft iris-core June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Newton Expires December5,29, 2003 [Page43]57] Internet-Draft iris-core June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Newton Expires December5,29, 2003 [Page44]58] ----