Network Working Group M. Rose Internet-Draft Dover Beach Consulting, Inc. Expires: December 24, 2002 June 25, 2002 The ANANA Datastore draft-anana-datastore-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts 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 December 24, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines the ANANA datastore, a policy-neutral service for managing registries, namespaces, and entries. Rose Expires December 24, 2002 [Page 1] Internet-Draft The ANANA Datastore June 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Datastore Model . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 XML Database Layer . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Policy Neutral Layer . . . . . . . . . . . . . . . . . . . . . 7 2.3 Policy-Defined Layer . . . . . . . . . . . . . . . . . . . . . 12 3. Datastore Operations . . . . . . . . . . . . . . . . . . . . . 15 3.1 Processing a Request . . . . . . . . . . . . . . . . . . . . . 16 3.2 Processing an Operation . . . . . . . . . . . . . . . . . . . 18 3.3 Trigger Evaluation . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Access Control Evaluation . . . . . . . . . . . . . . . . . . 20 4. Datastore Access . . . . . . . . . . . . . . . . . . . . . . . 23 4.1 Access Protocols . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Managing Authentication Information . . . . . . . . . . . . . 25 5. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1 The Operations DTD . . . . . . . . . . . . . . . . . . . . . . 27 5.2 The Registry DTD . . . . . . . . . . . . . . . . . . . . . . . 28 5.3 The AuthInfo DTD . . . . . . . . . . . . . . . . . . . . . . . 31 6. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1 The anana URI Scheme . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7.1 Registration: The anana URI Scheme . . . . . . . . . . . . . . 34 7.2 Registration: The System (Well-Known) TCP port number for the ANANA Datastore . . . . . . . . . . . . . . . . . . . . . 35 7.3 The application/anana+xml Media Type . . . . . . . . . . . . . 36 7.4 The ANANA Datastore Profile for BEEP . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 40 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42 Rose Expires December 24, 2002 [Page 2] Internet-Draft The ANANA Datastore June 2002 1. Introduction [1] introduces the concept of a policy-free registrar. To paraphrase: o a 'registrar' is a person, organization, or group that maintains a registry of names and numbers; o a 'registry' is a collection of one or more namespaces; o a 'namespace' is a collection of one or more blocks; o a 'block' is a collection of related entries; and, o an 'entry' is a binding between one or more 'keys' (each being unique within the namespace), a textual commentary, and zero or more 'citations' that further describe the entry. Consult [2] for an example of the provisioning strategy for a policy- free registrar. Typically, a registry contains a single namespace, which in turn contains a single block having many entries (with each entry having exactly one key). However, it may be desirable to have both multiple namespaces within a registry, and multiple blocks within a namespace. For example, if a registry corresponded to the parameters for a particular protocol, then: o that protocol might have different classes of parameters, so each parameter class would have its own namespace in the registry; similarly, o within a particular parameter class, it may be natural to divide the range of possible values into related blocks, e.g., "user- defined", "system-reserved", and so on. (Readers familiar with XML terminology should note that the term 'namespace', as used in this document, has no relationship to the 'XML namespace' concept.) Rose Expires December 24, 2002 [Page 3] Internet-Draft The ANANA Datastore June 2002 This memo describes a datastore that may be used to realize a policy- free registry service. As a reminder to the reader, the problem domain for the service has several notable requirements. In particular, the service: o supports registries that contain no more than a few million records; o supports registries that perform no more than a few updates each minute; o facilitates the separation of processes responsible for policy, allocation, and distribution; o facilitates automated (and mostly-automated) submissions; and, o facilitates transformation of registries from highly-structured to human-readable content. In particular, the reader should appreciate that the problem domain for this service is manifestly different than the one solved by traditional registry-registrar protocols, such as RRP[3]. Rose Expires December 24, 2002 [Page 4] Internet-Draft The ANANA Datastore June 2002 2. Datastore Model ANANA registries are modeled as XML[4] documents, and logically reside in a datastore with three conceptual layers: layer services approach ----- -------- -------- +-------------+ | | externally-defined services | reporting | are accessed via URI in policy-defined | | response to certain layer | conformance | datastore events | | +-------------+ | | | access | intra-document access policy neutral | control | control and structural layer | | (DTD) conformance | validity | +-------------+ | | | operations | a "generic" XML document XML database | | database (perhaps emulated layer | well- | by an RDBMS) | formedness | +-------------+ 2.1 XML Database Layer This layer is responsible for: o structuring information as a collection of well-formed XML documents; and, o providing operations to manage XML documents in the datastore. 2.1.1 Well-Formed XML The datastore contains XML documents, each of which correspond to a registry. Documents are uniquely identified using the ANANA URI (Section 6.1) scheme. Within a datastore, documents are named using the 'abs_path' syntax defined in RFC 2396[5] (e.g., "/anana/identities"). Within a document, fragments are named using an XML Path Language[6] (XPath) Rose Expires December 24, 2002 [Page 5] Internet-Draft The ANANA Datastore June 2002 expression (e.g., "//key[@id='anana']"). Note that since an XPath expression (typically) evaluates to a 'node-set' containing zero or more XML fragments, the number of fragments identified by this expression depends on the contents of the corresponding document. Any document residing in the datastore meets two requirements: o the document is well-formed (as described in Section 2.1 of [4]); and, o the only entities found in the document are XML's predefined entities (as defined in Section 4.6 of [4]) and numeric character references (as defined in Section 4.1 of [4]). The first requirement is essentially the "entry cost for doing XML". The second requirement limits the implementation complexity of the datastore and removes a large class of potential ambiguities when searching. Finally, the document named "/root", and any document whose name starts with "/root/", is reserved for use by the datastore. 2.1.2 Datastore Operations The datastore supports two sets of operations: o operations on documents; and, o operations on fragments within a document. Two document-wide operations are defined: o 'create', which creates a new document in the datastore; and, o 'delete', which removes an existing document from the datastore. Operations on the fragments within a document are specified using either: o an XPath expression, to retrieve XML fragments; or, o an XML Update Language[7] (XUpdate) expression, to modify an XML fragment. Note that in the interests of simplicity, the XUpdate expression is limited to a single modification per operation. Rose Expires December 24, 2002 [Page 6] Internet-Draft The ANANA Datastore June 2002 2.2 Policy Neutral Layer This layer is responsible for: o ensuring data consistency on XML documents that model ANANA registries; and, o enforcing access control policies. 2.2.1 Valid XML The ANANA Registry DTD (Section 5.2) defines the validity constraints for an XML document that models an ANANA registry. Each document has the '' element at its root. Each '' element contains: o a 'name' attribute uniquely identifying the registry, using a URI that conforms to the ANANA URI (Section 6.1) scheme; o a 'title' attribute containing a descriptive name for the registry; o a '' element containing: * one or more '' elements, each containing a pointer to registrar information; * optionally, a '' element containing textual information about the registry; and, * a '' element. o zero or more '' elements, each containing information about a namespace within the registry; and, o an '' element containing administrative information relating the XML document to the datastore, specifically: * an '' element containing zero or more '' elements, which defines the access control policy for the document; * a '' element containing zero or more '' elements, which defines the conformance policy for the document; and, * a '' element containing zero or more '' elements, which defines the reporting policy for the document. Rose Expires December 24, 2002 [Page 7] Internet-Draft The ANANA Datastore June 2002 The first fundamental concept about ANANA registries is that they are largely pointers to other resources, and often the resource is an XML fragment within the datastore. For example, here is the top-level and front part of an ANANA registry: This is the registry used by the ANANA to identify itself and other registrars. ... In this example, note that the value of the '' element's 'uri' attribute points to another portion of the document in which it resides. Each '' element contains: o an 'id' attribute that is unique within the document; o a 'title' attribute containing a descriptive name for the namespace; o optionally, a '' element containing textual information about the namespace; o a '