<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>

<rfc category="info" ipr="trust200902" docName="draft-birrane-dtn-ampmgr-sql-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">

<!-- ***** FRONT MATTER ***** -->
  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->
    <title abbrev="MGRSQL">AMP Manager SQL Interface</title>
    
    <author fullname="Edward J. Birrane" initials="E.B." surname="Birrane">
      <organization>Johns Hopkins Applied Physics Laboratory</organization>
      <address>
        <email>Edward.Birrane@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="Evana DiPietro" initials="E.D." surname="DiPietro">
      <organization>Johns Hopkins Applied Physics Laboratory</organization>
      <address>
        <email>Evana.DiPietro@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="David Linko" initials="D.L." surname="Linko">
      <organization>Johns Hopkins Applied Physics Laboratory</organization>
      <address>
        <email>David.Linko@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="Mark A. Sinkiat" initials="M.A." surname="Sinkiat">
      <organization>
        ASRC Space And Defense, NASA GSFC
      </organization>
      <address>
        <email>mark.a.sinkiat@nasa.gov</email>
      </address>
    </author>
    
    <date year="2018" />
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill
   in the current day and month for you. If the year is not the current one, it is
   necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
   purpose of calculating the expiry date).  With drafts it is normally sufficient to
   specify just the year. -->
    <!-- Meta-data Declarations -->
    <area>General</area>
    <workgroup>Delay-Tolerant Networking</workgroup>
    <keyword>DTN</keyword>
    <keyword>Network Management</keyword>
    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
         This document describes a proposed public interface through which an 
         application, such as a network management console, interacts with 
         an Asynchronous Management Protocol (AMP) Manager via a database
         supporting the Structured Query Language (SQL). The use of SQL as an 
         interfacing layer provides a natural way to describe interactions with 
         an AMP Manager independent of a particular implementation of either
         the Manager or the application. Specifically, this document presents 
         a database schema capturing how to send controls to a Manager and 
         how to accept reports received by a Manager from one or more AMP
         Agents.  
      </t>
    </abstract>
  
  </front>
 
   
  <middle>
    <section title="Introduction" toc="default">
      <t>
         This document presents a public interface through which an application,
         such as a network management console, interacts with an Asynchronous
         Management Protocol (<xref target="I-D.birrane-dtn-amp"/>) Manager via a database supporting the
         Structured Query Language (SQL). Such an interface is useful as an
         implementation independent way of specifying how an application 
         may interact with an AMP Manager to issue commands (such as through a 
         custom graphical user interface) and to receive reports (as they
         are received by one or more AMP Agents).
      </t>
               
      <section title="Purpose" toc="default">
      	 <t>
      	    This document describes a database layout comprised of a series 
      	    of names tables and the columns the comprise those tables. Where
      	    appropriate, primary and foreign key constraints are also discussed.
      	    This set of tables presents a data model through which all AMP
             Manager roles and responsibilities, as defined in the Asynchronous
             Management Architecture (<xref target="I-D.birrane-dtn-ama"/>), can be
             accomplished.      	    
          </t>       	
      	 <t>
      	    Application developers can use this specification to describe how
      	    to populate a database with AMP-related information such that an
      	    AMP Manager implementation can read and use this data to effect
      	    AMP behavior. By reading and writing the tables in accordance with
      	    this specification, applications can claim conformance with the
      	    AMP Manager regardless of which AMP Manager implementation is used,
      	    so long as such a Manager is also in conformance with this
      	    specification.
          </t>    
          <t>
             AMP Manager developers use this specification to describe how AMP
             users input actions to the Manager and how to send received reports
             back to those users. 
          </t>
      </section>
      
      <section title="Scope" toc="default">
         <t>
            This document covers table names and the names, data types, 
            default values, and comments associated with each column of each
            names table. These types should be appropriate for any database
            implementing a SQL interface and SHOULD NOT use any language
            or function specific to a particular SQL database vendor.
         </t>
         <t>
            This document does not specify the setup, configuration, administration,
            or other function associated with a particular SQL database
            vendor. Further, this document does not specify how either the
            application or the AMP Manager log on to the database, or how
            database communications are verified and secured. Finally, this 
            document does not discuss the architecture associated with 
            incorporating a database between an application and an AMP Manager,
            as such architectures are likely tightly coupled to a network
            deployment. 
         </t>
      </section>
      
      <section title="Requirements Language" toc="default">
        <t>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 <xref target="RFC2119" pageno="false" format="default">RFC 2119</xref>.</t>
      </section>
    </section>
 
    
   
    <section title="Database Overview" toc="default">
       <t>
          This specification assumes that all tables exist in a database called
      	 "amp_core", capturing the information necessary to capture core
      	 operations associated with the AMP Manager.
       </t>
       <t>
          The schema contains tables capturing information about various areas of
          the AMP Manager interface. The following table types are defined.
         
          <list hangIndent="8" style="symbols">
             <t>
                Constants - These tables contain those constants defined in the
                AMP and AMA specifications as well as certain constants that are
                defined in this specification. 
             </t>
             <t>
                ADM Support - These tables capture all information that is solely
                defined in an ADM. Outside of adding support for a new ADM, the
                data in these tables should never be changed.
             </t>
             <t>
                AMP Agent Support - These tables capture information about
                Agents in the system.
             </t>
             <t>
                Compound Data Types Support- These tables capture information
                about TNVCs and expressions.
             </t>
             <t>
                Operator Support- These tables capture the information that is
                needed to utilize operators.
             </t>
             <t>
                ARI Information - These tables capture all information used to
                define Managed Identifiers (ARIs) for the Manager. This includes
                ARI definitions from ADMs custom definitions from users in the system.
                These tables also capture parameters, object identifiers, and ARI
                collections.
             </t>
             <t>
                Outgoing Support - These tables capture information provided
                by an application to a Manager to be sent out to an AMP agent. 
             </t>
             <t>
                Incoming Support - These tables capture information provided
                by an Agent and incoming to the Manager to be passed along to the
                application.
             </t>
          </list>
       </t>

       <t>
          The specification comprises tables, as in
          <xref target="tables"/>. 
            
          <figure align="center" anchor="tables" title="amp_core tables" suppress-title="false" alt="" width="" height="">               
             <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+-----------------------+------------------------+
| Table Name            | Table Type             |
+-----------------------+------------------------+
| data_type             | Constants              |
| incoming_state        | Constants              |
| outgoing_state        | Constants              |
| tnvc_set              | Compound Data Type     |
| tnvc                  | Compound Data Type     |
| expression_set        | Compound Data Type     |
| expression            | Compound Data Type     |
| in_type_set           | Operator Support       |
| in_type               | Operator Support       |
| adm_nickname          | ADM Support            |
| adm                   | ADM Support            |
| parmspec              | ADM Support            |
| parmspec_set          | ADM Support            |
| registered_agents     | Agent Support          |      
| data                  | ARI Information        |
| data_set              | ARI Information        |
| ac                    | ARI Information        |
| ac_set                | ARI Information        |
| ari                   | ARI Information        |
| ari_definition        | ARI Information        |
| outgoing_message_group| Outgoing Support       |
| outgoing_message      | Outgoing Support       |                     
| incoming_message_group| Incoming Support       |
| incoming_message      | Incoming Support       |
+-----------------------+------------------------+
             </artwork>
          </figure>            
       </t>
       
    </section>
    
   
   
   
    <section title="Constants" toc="default">
       <section title="Data Types - data_types">
          <t>
             Data types, as defined in the AMP, enumerate the types of information associated
             with collections of data, such as defined in ARI parameters, computed values, and
             report definitions. 
          </t>
          <t>
             The format of the table is as follows.
           
             <figure align="center" title="data_types" suppress-title="false">               
               <artwork align="center" xml:space="preserve">
+-------------+------------------+------+-----+---------+-------+
| Field       | Type             | Null | Key | Default | Extra |
+-------------+------------------+------+-----+---------+-------+
| enumeration | int(10) unsigned | NO   | PRI |         |       |
| name        | varchar(50)      | NO   | UNI |         |       |
| description | varchar(255)     | NO   |     | ""      |       |
+-------------+------------------+------+-----+---------+-------+
               </artwork>
             </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="enumeration"><vspace blankLines="0" /> 
                 The primary key for this table, and the enumerated value of the
                 data type from the AMP specification.
              </t>
                  
              <t hangText="Name"><vspace blankLines="0" /> 
                 The name associated with this data type.
              </t>
                                    
              <t hangText="Description"><vspace blankLines="0" />
                 The description associated with this data type.
              </t>
           </list>
        </t>
        
        <t>
           An example of such a table is illustrated in <xref target="I-D.birrane-dtn-adm"/>.
        </t>                
     </section>

     <section title="Incoming State - incoming_state">
        <t>
           When reports are being received by a Manager from an Agent, they will
           be written into various Incoming Support table types. However, the 
           application reviewing these incoming reports should not start to read
           them until the Manager has finished receiving and persisting them into the
           database. 
        </t>
        <t>
           The incoming_state table identifies three different wait states associated
           with receiving reports from Agents. The format of the table is defined as
           follows.
           
           <figure align="center" title="incoming_state" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+-------------+---------------------+------+-----+---------+-------+
| Field       | Type                | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| state_id    | tinyint(3) unsigned | NO   | PRI |         |       |
| name        | varchar(50)         | NO   |     |         |       |
| description | varchar(255)        | NO   |     |         |       |
+-------------+---------------------+------+-----+---------+-------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="state_id"><vspace blankLines="0" /> 
                 The primary key for this table, and the enumerated value of the
                 incoming state. Three states are defined in this specification, 
                 as follows.
                 
                 <list hangIndent="8" style="hanging">
                    <t hangText="0 - Initializing"><vspace blankLines="0" />
                       This state signifies that a Manager is receiving a set of 
                       information and rows associated with this state should not
                       be read by an application.                     
                    </t>
                    <t hangText="1 - Ready"><vspace blankLines="0" />
                       This state signifies that a Manager has completed receiving
                       reports and that rows associated with this state may be
                       processed by an application.                     
                    </t>
                    <t hangText="2 - Processed"><vspace blankLines="0" />
                       This state signifies that an application has completed 
                       processing reports and that either a Manager or an
                       application can remove rows associated with this
                       state at any time.                     
                    </t>                                  
                 </list>
              </t>
                  
              <t hangText="Name"><vspace blankLines="0" /> 
                 The name associated with the incoming state (Initializing, Ready, Processed).
              </t>
                                    
              <t hangText="Description"><vspace blankLines="0" />
                 The description associated with the incoming state.
              </t>
           </list>
        </t>
        
        <t>
           An example of such a table is illustrated below.
           
           <figure align="center" title="incoming_state example" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+----+--------------+-----------------------------------------+
| ID | Name         | Description                             |
+----+--------------+-----------------------------------------+
|  0 | Initializing | Manager is receiving reports.           |
|  1 | Ready        | Manager has completed reception.        |
|  2 | Processed    | Application is done processing reports. |
+----+--------------+-----------------------------------------+
              </artwork>
           </figure>
        </t>                
     </section>


     <section title="Outgoing State - outgoing_state">
        <t>
           When controls are being sent via a Manager to an Agent, they  will
           be written into various Outgoing Support table types. However, the 
           Manager receiving these outgoing controls should not start to read
           them until the application has finished writing them into the
           database. 
        </t>
        <t>
           The outgoing_state table identifies four different wait states associated
           with sending controls to Agents. The format of the table is defined as
           follows.
           
           <figure align="center" title="outgoing_state" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+-------------+--------------+------+-----+---------+-------+
| Field       | Type         | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| state_id    | tinyint(4)   | NO   | PRI |         |       |
| name        | varchar(50)  | NO   |     |         |       |
| description | varchar(255) | NO   |     |         |       |
+-------------+--------------+------+-----+---------+-------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="state_id"><vspace blankLines="0" /> 
                 The primary key for this table, and the enumerated value of the
                 outgoing state. Four states are defined in this specification, 
                 as follows.
                 
                 <list hangIndent="8" style="hanging">
                    <t hangText="0 - Initializing"><vspace blankLines="0" />
                       This state signifies that an application is preparing a set of 
                       controls and rows associated with this state should not
                       be read by a Manager.                     
                    </t>
                    <t hangText="1 - Ready"><vspace blankLines="0" />
                       This state signifies that an application has completed preparing
                       the controls and that rows associated with this state may be
                       processed by the Manager for sending to one or more Agents.                     
                    </t>
                    <t hangText="2 - Processing"><vspace blankLines="0" />
                       This state signifies that the Manager is in the process of sending
                       associated controls to one or more Agents. Rows in this state should
                       not be modified by an application as it could affect the controls
                       sent by the Manager.
                    </t>                                  
                    <t hangText="3 - Sent"><vspace blankLines="0" />
                       This state signifies that the Manager has completed sending the 
                       set of controls and that either a Manager or an
                       application can remove rows associated with this
                       state at any time.                     
                    </t>                                  
                    
                 </list>
              </t>
                  
              <t hangText="name"><vspace blankLines="0" /> 
                 The name associated with the outgoing state (Initializing, Ready, Processing, Sent).
              </t>
                                    
              <t hangText="description"><vspace blankLines="0" />
                 The description associated with the outgoing state.
              </t>
           </list>
        </t>
        
        <t>
           An example of such a table is illustrated below.
           
           <figure align="center" title="outgoing_state Example" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+----------+--------------+---------------------------------+
| state_id | name         | description                     |
+----------+--------------+---------------------------------+
|  0       | Initializing | Application writing controls.   |
|  1       | Ready        | Ready for Sending to Agent.     |
|  2       | Processing   | Manager sending controls.       |
|  3       | Sent         | Manager send completed.         |
+----------+--------------+---------------------------------+
              </artwork>
           </figure>
        </t>                
     </section>

    
  </section>   
     
  
   
  <section title="ADM Support" toc="default">
     
     <section title="ADM Nicknames - adm_nickname">
        <t>
           The adm_nicknames table identifies all of the nicknames associated
           with supported ADMs. A Nickname is the compression of a shared
           portion of an ARI. Nickname enumerations MUST be unique. The 
           format of the table is defined as follows.
           
           <figure align="center" title="adm_nicknames" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+----------------+------------------+------+-----+---------+-------+
| Field          | Type             | Null | Key | Default | Extra |
+----------------+------------------+------+-----+---------+-------+
| adm_id         | int(10) unsigned | NO   | MUL |         |       |
| nickname_enum  | int(10) unsigned | NO   |     |         |       |
| label          | varchar(255)     | NO   |     |         |       |
+----------------+------------------+------+-----+------------+----+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="adm_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>
                               
              <t hangText="nickname_enum"><vspace blankLines="0" />
                 The enumeration of the nickname.
              </t>
              <t hangText="label"><vspace blankLines="0" />
                 This is the label of the nickname.
              </t>
              
              
              
           </list>
        </t>        
     </section>
     

     
     <section title="Supported ADMs - adm">
        <t>
           The adm table identifies all of the ADMs supported by the
           AMP Manager and associated application. The format of the 
           table is as follows.
           
           <figure align="center" title="adm" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+-------------+-----------------+------+-----+---------+---------------+
| Field       | Type            | Null | Key | Default | Extra         |
+-------------+-----------------+------+-----+---------+---------------+
| adm_id      | int(10) unsigned| NO   | PRI |         | auto_increment|
| name        | varchar(255)    | NO   | UNI |         |               |
| version     | varchar(255)    | NO   |     |         |               |
| description | varchar(255)    | NO   |     |         |               |
| Organization| varchar(255)    | NO   |     |         |               |
+--------------+------------------+------+-----+---------+-------------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="adm_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>
                  
              <t hangText="name"><vspace blankLines="0" /> 
                 The name of the supported ADM.
              </t>
                                    
              <t hangText="version"><vspace blankLines="0" />
                 The string representing the version of the ADM. A string is
                 used to allow for a variety of version formats.
              </t>
              
              <t hangText="description"><vspace blankLines="0" />
                 This is the description of the ADM.
              </t>

              <t hangText="Organization"><vspace blankLines="0" />
                 This is the issuing organization of the ADM.
              </t>
           </list>
        </t>        
     </section>
          
     
     <section title="ARIs">
        <t>
           ARIs identifying items such as Controls may accept parameters to
           customize their behavior. When defined in the context of an ADM,
           a parameterized ARI only includes the non-parameterized portion
           of the ARI followed by the expected data types for the parameterized
           portion of the ARI. This, essentially, acts as a template for
           populating a specific instance of the ARI with actual data.
        </t>
        
        <t>
           This "template" is referred to as a ARI, as it is used to
           generate ARI instances. The instances of an ARI are called
           ARI definitions. The amp_core database schema identifies
           three tables used to capture ARI definitions from ADMs:
           parmspec, parmspec_set, ari, and ari_definition. 
        </t>
        
        <section title="Individual ARI Parameter - parmspec">
           <t>
              The parmspec table contains a row for each 
              parameter associated with an ARI. All of the parameters for
              an ARI, together, are considered a "collection" of parameters.
              The format of the table is as follows.
           
           <figure align="center" title="parmspec" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+-----------+------------------+------+-----+---------+-------+
| Field     | Type             | Null | Key | Default | Extra |
+-----------+------------------+------+-----+---------+-------+
| name      | varchar(45)      | NO   |     |         |       |
| parm_id   | int(10) unsigned | YES  | MUL | NULL    |       |
| parm_order| int(10) unsigned | NO   | UNI | 0       |       |
| type_id   | int(10) unsigned | YES  | MUL | NULL    |       |
+-----------+------------------+------+-----+---------+-------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="name"><vspace blankLines="0" /> 
                 The name of the parmspec collection.
              </t>
                  
              <t hangText="parm_id"><vspace blankLines="0" /> 
                 The id of the collection for this parameter. A parameter
                 collection is the ordered set of parameters that describe
                 an ARI. This is a foreign key that corresponds to the parm_id
                 of the parmspec_set table.
              </t>
                                    
              <t hangText="parm_order"><vspace blankLines="0" />
                 The 0-based ordering of this parameter within the collection.
              </t>
              
              <t hangText="type_id"><vspace blankLines="0" />
                 The type of this parameter. This must be one of the known
                 AMP types and, as such, is a foreign key that corresponds to the
                 enumeration of the data_type table.
              </t>
           </list>
        </t>        
     </section>
          


     <section title="ARI Parameter Collection - parmspec_set">
           <t>
              The parmspec_set table represents the ordered set of
              parameters associated with an ARI. The format of the table is as follows.
           
           <figure align="center" title="parmspec_set" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+---------+------------------+------+-----+--------+----------------+
| Field   | Type             | Null | Key | Default| Extra          |
+---------+------------------+------+-----+--------+----------------+
| parm_id | int(10) unsigned | NO   | PRI |        | auto_increment | 
|comment  | varchar(255)     | NO   |     |        |                |
+---------+------------------+------+-----+--------+----------------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="parm_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>
              <t hangText="comment"><vspace blankLines="0" /> 
                 This is the description of the parmspec set.
              </t>
                  
           </list>
        </t>        
     </section>
     
     <section title="ARI - ari">
      <t>
        The ari table captures the ARIs in the database.  Some ARIs will
        be auto-populated from ADMs.  Others will be added dynamically by
        users of the system.  As per [AMP], an ARI without an identified
        Issuer field is assumed to be as defined in an ADM.  The format of
        the table is defined as follows.

        <figure align="center" title="ari" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+--------------+-------------------+------+-----+----------+----------+
| Field        | Type              | Null | Key | Default  | Extra    |
+--------------+-------------------+------+-----+----------+----------+
| curr_id      | int(10) unsigned  | NO   | PRI |          |          |
| name         | varchar(50)       | NO   | UNI | Unnamed  |          |
| ari_id       | int(10) unsigned  | NO   | MUL |          |          |
| data_id      | int(10) unsigned  | NO   | MUL |          |          |
| description  | varchar(255)      | YES  |     |          |          |
+--------------+-------------------+------+-----+----------+----------+ 

</artwork>
</figure>

<list hangIndent="8" style="hanging">
              <t hangText="curr_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>

              <t hangText="name"><vspace blankLines="0" /> 
                 The name of the ARI.
              </t>

              <t hangText="ari_id"><vspace blankLines="0" /> 
                 This is the id of the ARI. This is a foreign key 
                 that corresponds to the ari_id in
                 the ari_definition table.
              </t>

              <t hangText="data_id"><vspace blankLines="0" /> 
                 This is a foreign key to the data_set table that corresponds
                 with the data_id of the data_set table.
              </t>
              <t hangText="description"><vspace blankLines="0" /> 
                 This is the description of the ari.
              </t>
              </list>
</t>
</section>



     <section title="ARI - ari_definition">
           <t>
              The ari_definition table stores the metadata of all known ARIs. The 
              format of the table is as follows.
           
           <figure align="center" title="ari_definition" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+---------------+-----------------+------+-----+---------+----------+
| Field         | Type            | Null | Key | Default | Extra    |
+---------------+-----------------+------+-----+---------+----------+
| ari_id        | int(10) unsigned| NO   | PRI |         | auto_inc |
| name          | varchar(50)     | NO   | UNI | Unnamed |          |
| type_id       | int(10) unsigned| NO   | MUL | NULL    |          |
| nn_id         | int(10) unsigned| YES  | MUL | NULL    |          |
| ari_bytestring| varchar(255)    | NO   |     |         |          |
| parm_id       | int(10) unsigned| YES  | MUL | NULL    |          |
| issuer        | bigint unsigned | YES  |     | NULL    |          |
| tag           | bigint unsigned | YES  |     | NULL    |          |
| structure_id  | varchar(255)    | YES  | MUL | NULL    |          |
| in_type_id    | int(10) unsigned| YES  | MUL | NULL    |          |
+---------------+-----------------+------+-----+---------+----------+ 
             </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="ari_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>

              <t hangText="nn_id"><vspace blankLines="0" /> 
                 The nickname associated with this ARI, if applicable. This is
                 a foreign key that corresponds to the id in the adm_nickname
                 table.
              </t>

              
              <t hangText="parm_id"><vspace blankLines="0" /> 
                 The parameter collection for this ARI. This is a foreign
                 key that corresponds to the parm_id in the parm_set table.
              </t>

              <t hangText="issuer_flag"><vspace blankLines="0" />
                 A binary value representing whether the ARI has an issuer
                 field (value 1) or not (value 0).               
              </t>

              <t hangText="tag_flag"><vspace blankLines="0" />
                 A binary value representing whether the ARI has a tag
                 field (value 1) or not (value 0).               
              </t>


              <t hangText="type_id"><vspace blankLines="0" /> 
                 The data type associated with this ARI. This is a foreign
                 key that corresponds to the data_id in the data_types table.
              </t>


              <t hangText="name"><vspace blankLines="0" /> 
                 A human-readable name for this ARI.
              </t>
                                                                                                                                                                            
              <t hangText="ari_bytestring"><vspace blankLines="0" /> 
                 The enumeration of the ARI.
              </t>

              <t hangText="structure_id"><vspace blankLines="0" /> 
                 This is the structure type of the ARI (EDD, VAR,etc.). This
                 is a foreign key that corresponds to the data_id in the
                 data_types table.
              </t>

              <t hangText="in_type_id"><vspace blankLines="0" /> 
                 This is the in types that are needed to use a specific
                 operator. This is a foreign key that corresponds to the
                 in_type_id in the in_type_set table. 
              </t>

           </list>
        </t>        
     </section>                       
  </section>
     </section>
  
   <section title="Agent Support" toc="default">
   
     <section title="Registered Agents - registered_agents">
        <t>
           The registered_agents table lists the network identifiers for
           each Agent known in the network. The format of the table is defined as
           follows.
           
           <figure align="center" title="registered_agents" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+------------+-----------------+------+-----+---------+---------------+
| Field      | Type            | Null | Key | Default | Extra         |
+------------+-----------------+------+-----+---------+---------------+
| registry_id| int(10) unsigned| NO   | PRI |         | auto_increment|
| agent_id   | varchar(128)    | NO   |     | ipn:0.0 |               |
+------------+-----------------+------+-----+---------+---------------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="registry_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>
                  
              <t hangText="agent_id"><vspace blankLines="0" /> 
                 This is the identifier for the Agent, suitable for passing
                 into a network send call. A string representation is selected
                 to best capture the identifier format for a particular network.                 
              </t>
           </list>
        </t>        
     </section>
   </section>
   
   
   
   <section title="ARI Information" toc="default">
   
      <section title="Data Collections">
         <t>
            Data collection tables capture the Data Collection (DC) data type
            as defined in <xref target="I-D.birrane-dtn-amp"/>. Similar to the parmspec and 
            parmspec_set tables, Data Collections are represented as an ordered 
            collection of individual data items, with one table representing the 
            collection itself, and another table holding the ordered data 
            within the collection.
         </t>
         
         <section title="Data Collection Entry - data_value">
            <t>
               The data_value table holds data collection entries, one per
               row. The format of the table is defined as follows.
           
               <figure align="center" title="data_value" suppress-title="false">               
                  <artwork align="center" xml:space="preserve">
+------------+------------------+------+-----+---------+-------+
| Field      | Type             | Null | Key | Default | Extra |
+------------+------------------+------+-----+---------+-------+
| data_id    | int(10) unsigned | NO   | MUL |         |       |
| data_order | int(10) unsigned | NO   | UNI | 0       |       |
| data_type  | int(10) unsigned | NO   | MUL |         |       |
| ari_id     | blob             | YES  | MUL | NULL    |       |
| byte       | longblob         | YES  |     | NULL    |       |
| tnvc_id    | int(10) unsigned | NO   | MUL |         |       |
| ac_id      | int(10) unsigned | NO   | MUL |         |       |
| vast       | bigint           | YES  |     | NULL    |       |
| uvast      | bigint unsigned  | YES  |     | NULL    |       |
| real       | longblob         | YES  |     | NULL    |       |
| str        | varchar(255)     | YES  |     | NULL    |       |
| bool       | boolean          | YES  |     | NULL    |       |
| ts         | datetime         | YES  |     | NULL    |       |
+------------+------------------+------+-----+---------+-------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="data_id"><vspace blankLines="0" /> 
                     The id of the data collection. This is a foreign key 
                     that corresponds with the data_id of the data_set table.
                  </t>
                  
                  <t hangText="data_order"><vspace blankLines="0" /> 
                     The 0-based order of this entry in the encapsulating 
                     collection.                 
                  </t>
              
                  <t hangText="data_type"><vspace blankLines="0" /> 
                     The type of this data collection. This is a foreign key that
                     corresponds to the enumeration in the data_types table.
                  </t>
                  
                  <t hangText="tnvc_id"><vspace blankLines="0" /> 
                     This is a foreign key that corresponds to the tnvc_id of the tnvc_set table.                                  
                  </t>

                  <t hangText="ac_id"><vspace blankLines="0" /> 
                     This is a foreign key that corresponds to the ac_id of the ac_set table.                                 
                  </t>

                  <t hangText="byte"><vspace blankLines="0" />
                      The byte value shows the value of the data (if the piece of data
                      is a byte). If the data is not a byte, this field MUST be NULL.
                  </t>


                  <t hangText="vast"><vspace blankLines="0" />
                      The vast value shows the value of the data (if the piece of data is
                      of type int or vast). If the data is not an int or vast, this field
                      MUST be NULL.
                  </t>

                  <t hangText="uvast"><vspace blankLines="0" />
                      The uvast value shows the value of the data (if the piece of data is
                      of type uint or vast). If the data is not an uint or uvast, this field
                      MUST be NULL.
                  </t>

                  <t hangText="real"><vspace blankLines="0" />
                      The real value shows the value of the data (if the piece of data is
                      of type real32 or real64). If the data is not a real32 or real64, this
                      field MUST be NULL.
                  </t>


                  <t hangText="Str"><vspace blankLines="0" />
                      The str field shows the value of the data (if the piece of data is of 
                      type string). If the data is not a string, this field MUST be NULL.
                  </t>

                  <t hangText="Bool"><vspace blankLines="0" />
                      The bool field shows the value of the data (if the piece of data is of 
                      type boolean). If the data is not a boolean, this field MUST be NULL.
                  </t>

                  <t hangText="ts"><vspace blankLines="0" />
                      The ts field shows the value of the data (if the piece of data is of 
                      type timestamp). If the data is not a timestamp, this field MUST be NULL.
                  </t>

                            
               </list>
            </t>        
         </section>
         
         <section title="Data Collection - data_set">
            <t>
               The data_collection_set table holds information for a particular
               collection of data entries (from data_value). The format 
               of the table is defined as follows.
           
               <figure align="center" title="data_set" suppress-title="false">               
                  <artwork align="center" xml:space="preserve">
+-------+------------------+------+-----+----------+----------------+
| Field | Type             | Null | Key | Default  | Extra          |
+-------+------------------+------+-----+----------+----------------+
|data_id| int(10) unsigned | NO   | PRI |          | auto_increment |
|comment| varchar(255)     | NO   |     |          |                |
+-------+------------------+------+-----+----------+----------------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="data_id"><vspace blankLines="0" /> 
                     The Data Collection identifier. This is a primary
                     key.
                  </t>
                  <t hangText="comment"><vspace blankLines="0" /> 
                     This is a description of the data set.
                  </t>

               </list>
            </t>        
         </section>         
         
      </section>
      
      <section title="ARI Collections">
         <t>
            A ARI Collection is an ordered set of ARI values, similar to a 
            Data Collection, which is an ordered set of Data values. One table
            is used to represent the ARI Collection, and another table is used
            to capture the ordered ARIs in the collection.
         </t>
         
         <section title="ARI Collection Entry - ac">
            <t>
               The ac table holds ARI collection entries, one per
               row. The format of the table is defined as follows.
           
               <figure align="center" title="ac" suppress-title="false">               
                  <artwork align="center" xml:space="preserve">
+----------+------------------+------+-----+---------+-------+
| Field    | Type             | Null | Key | Default | Extra |
+----------+------------------+------+-----+---------+-------+
| ac_id    | int(10) unsigned | NO   | MUL |         |       |
| ac_order | int(10) unsigned | NO   |     | 0       |       |
| ari_id   | int(10) unsigned | NO   | MUL |         |       |
+----------+------------------+------+-----+---------+-------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ac_id"><vspace blankLines="0" /> 
                     The ARI Collection to which this entry belongs.
                     This is a foreign key that corresponds with the ac_id of
                     the ac_set table. 
                  </t>
                  
                  <t hangText="ari_id"><vspace blankLines="0" /> 
                     The identifier for this ARI. This is a foreign key that corresponds to the ari_id in the ari_definition table.               
                  </t>             
                                    
                  <t hangText="ac_order"><vspace blankLines="0" /> 
                     The 0-based order of this entry in the encapsulating 
                     collection.                 
                  </t>             
                            
               </list>
            </t>        
         </section>

                  
         <section title="ARI Collection - ac_set">
            <t>
               The ac_set table holds information for a particular
               collection of ARIs (from the ac table). The format 
               of the table is defined as follows.
           
               <figure align="center" title="ac_set" suppress-title="false">               
                  <artwork align="center" xml:space="preserve">
+---------+------------------+------+-----+---------+----------------+
| Field   | Type             | Null | Key | Default | Extra          |
+---------+------------------+------+-----+---------+----------------+
| ac_id   | int(10) unsigned | NO   | PRI |         | auto_increment |
| comment | varchar(255)     | NO   |     |         |                |
+---------+------------------+------+-----+---------+----------------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ac_id"><vspace blankLines="0" /> 
                     The ARI Collection identifier.
                  </t>
                  
               </list>
            </t>        
         </section>   
                  
      </section>
  </section>
  <section title="Operator Support">
       <section title="In Type Set - in_type_set">
            <t>
               The in_type_set table holds information for a particular
               collection of operator in types (from the in_types table).
               The format of the table is defined as follows.
           
               <figure align="center" title="in_type_set" suppress-title="false">               
                  <artwork align="center" xml:space="preserve">
+----------+------------------+------+-----+---------+----------------+
| Field    | Type             | Null | Key | Default | Extra          |
+----------+------------------+------+-----+---------+----------------+
|in_type_id| int(10) unsigned | NO   | PRI |         | auto_increment |
| comment  | varchar(255)     | NO   |     |         |                |
+----------+------------------+------+-----+---------+----------------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="in_type_id"><vspace blankLines="0" /> 
                     The in_type set identifier.
                  </t>
                  <t hangText="comment"><vspace blankLines="0" /> 
                     The description of the in_type set.
                  </t>
                  
               </list>
            </t>        
         </section>

         <section title="In Type - in_type">
            <t>
               The in_type table holds information about operator
               in types. The format of the table is defined as follows.
           
               <figure align="center" title="in_type_set" suppress-title="false">               
                  <artwork align="center" xml:space="preserve">
+----------+------------------+------+-----+---------+----------------+
| Field    | Type             | Null | Key | Default | Extra          |
+----------+------------------+------+-----+---------+----------------+
|in_type_id| int(10) unsigned | NO   | PRI |         | auto_increment |
|  name    | varchar(255)     | NO   |     |         |                |
|  order   | int(10) unsigned | NO   |     |         |                |
| type id  | int(10) unsigned | NO   | MUL |         |                |
+----------+------------------+------+-----+---------+----------------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="in_type_id"><vspace blankLines="0" /> 
                     The in_type set identifier. This is a foreign key
                     that corresponds to the in_type_id of the
                     in_type_set table.
                  </t>
                  <t hangText="name"><vspace blankLines="0" /> 
                     The name of the operator in type.
                  </t>
                  <t hangText="order"><vspace blankLines="0" /> 
                     The order of the operator in type in the set.
                  </t>
                  <t hangText="type id"><vspace blankLines="0" /> 
                     This is the type of the operator in_type. This is
                     a foreign key that corresponds to the enumeration
                     in the data_types table.
                  </t>
                  
               </list>
            </t>        
         </section> 
         </section>   

   
   <section title="Outgoing Message Support" toc="default">
      <t>
         Outgoing messages are those that are written into the database by
         an application and read by an AMP Manager, formatted, and sent to
         one or more AMP Agents. 
      </t>
      <t>
         The database represents outgoing messages in two tables. One table
         holds information for the entire outgoing message group, and another
         table captures each individual outgoing message. An individual outgoing
         message is simply a ARI collection of the ARIs to be run on the Agent.
      </t>
      
      <section title="Outgoing Messages - outgoing_message">
        <t>
           The outgoing_message table captures a single ARI Collection
           holding the set of Control ARIs to be sent to an Agent as part of 
           a Message Group. The 
           format of the table is defined as follows.
           
           <figure align="center" title="outgoing_message" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+------------+-----------------+------+-----+---------+---------------+
| Field      | Type            | Null | Key | Default | Extra         |
+------------+-----------------+------+-----+---------+---------------+
| message_id | int(10) unsigned| NO   | PRI |         | auto_increment|
| group_id   | int(10) unsigned| NO   | MUL |         |               |
| start_ts   | datetime        | NO   |     | 0       |               |
| ac_id      | int(10) unsigned| NO   | MUL |         |               |
+------------+-----------------+------+-----+---------+---------------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="message_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>

              <t hangText="group_id"><vspace blankLines="0" /> 
                 The outgoing message group to which this outgoing message
                 belongs. This is a foreign key that corresponds to the id in
                 the outgoing_message_group table.
              </t>
                                              
              <t hangText="start_ts"><vspace blankLines="0" /> 
                 The time at which the controls in the ARI Collection should
                 be run. This may be an absolute or relative time, as defined
                 in <xref target="I-D.birrane-dtn-amp"/>.
              </t>
              
              <t hangText="ac_id"><vspace blankLines="0" /> 
                 The ARI Collection comprising this outgoing message. This is a
                 foreign key that corresponds to the ac_id of the ac_set 
                 table.                  
              </t>
           </list>
        </t>        
     </section>
      
     <section title="Outgoing Message Groups - outgoing_message_group">
        <t>
           The outgoing_message_group table captures an outgoing message
           group, which is one or more outgoing messages. The 
           format of the table is defined as follows.
           
           <figure align="center" title="outgoing_message_group" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+------------+-----------------+------+-----+---------+---------------+
| Field      | Type            | Null | Key | Default | Extra         |
+------------+-----------------+------+-----+---------+---------------+
| group_id   | int(10) unsigned| NO   | PRI |         | auto_increment|
| created_ts | datetime        | YES  |     | NULL    |               |
| modified_ts| datetime        | YES  |     | NULL    |               |
| state      | tinyint(4)      | NO   | MUL |         |               |
| agent_id   | int(10) unsigned| NO   | MUL |         |               |
+------------+-----------------+------+-----+---------+---------------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="group_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>

              <t hangText="created_ts"><vspace blankLines="0" /> 
                 The time at which the outgoing message group was created.
              </t>
                                              
              <t hangText="modified_ts"><vspace blankLines="0" /> 
                 The last time at which the message group was modified.
              </t>
              
              <t hangText="state"><vspace blankLines="0" /> 
                 The current state of the outgoing message group. This state
                 provides a contention-avoidance mechanism between
                 an application and an AMP Manager. This is a foreign key
                 that corresponds to the state_id of the outgoing_state table.
              </t>
              
              <t hangText="agent_id"><vspace blankLines="0" /> 
                 The identifier of the Agent receiving this message group. 
                 Currently, a message group is only sent to one Agent. Sending
                 to multiple Agents is accomplished with multiple entries in 
                 this table. This is a foreign key that corresponds to the registry_id
                 in the registered_agents table.             
              </t>
                            
           </list>
        </t>        
     </section>
   </section>
     
   <section title="Incoming Message Support" toc="default">
    <t>
         Incoming messages are those that are written into the database by
         an AMP Manager and read by an application wishing to understand the 
         status of an AMP Agent.
      </t>
      <t>
         The database represents incoming messages in two tables. One table
         holds information for the entire incoming message group, and another
         table captures each individual incoming message. 
      </t>
      
      <section title="Incoming Messages - incoming_messages">
        <t>
           The incoming_messages table captures information returned from 
           an AMP Agent. The 
           format of the table is defined as follows.
           
           <figure align="center" title="incoming_messages" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+------------+-----------------+------+-----+---------+---------------+
| Field      | Type            | Null | Key | Default | Extra         |
+------------+-----------------+------+-----+---------+---------------+
| message_id | int(10) unsigned| NO   | PRI | NULL    | auto_increment|
| group_id   | int(10) unsigned| NO   | MUL | NULL    |               |
| ac_id      | int(10) unsigned| YES  | MUL | NULL    |               |
+------------+-----------------+------+-----+---------+---------------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="message_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>

              <t hangText="group_id"><vspace blankLines="0" /> 
                 The incoming message group to which this incoming message
                 belongs. This is a foreign key that corresponds with the
                 group_id in the incoming_message_group table.
              </t>
                                              
              <t hangText="ac_id"><vspace blankLines="0" /> 
                 This is a foreign key that corresponds to the id in the ac_set
                 table.                  
              </t>
           </list>
        </t>        
     </section>
      
     <section title="Incoming Message Groups - incoming_message_group">
        <t>
           The incoming_message_group table captures an incoming message
           group, which is one or more incoming messages. The 
           format of the table is defined as follows.
           
           <figure align="center" title="incoming_message_group" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+-------------+---------------------+------+-----+---------+-----------+
| Field       | Type                | Null | Key | Default | Extra     |
+-------------+---------------------+------+-----+---------+-----------+
| group_id    | int(10) unsigned    | NO   | PRI |         | auto_incr |
| recieved_ts | datetime            | YES  |     | NULL    |           |
| generated_ts| datetime            | YES  |     | NULL    |           |
| state       | tinyint(3) unsigned | NO   | MUL |         |           |
| agent_id    | int(10) unsigned    | NO   | MUL |         |           |
+-------------+---------------------+------+-----+---------+-----------+
              </artwork>
           </figure>
               
           <list hangIndent="8" style="hanging">
              <t hangText="group_id"><vspace blankLines="0" /> 
                 The primary key for this table.
              </t>

              <t hangText="recieved_ts"><vspace blankLines="0" /> 
                 The time at which the incoming message group was received
                 by the AMP Manager.
              </t>
                                              
              <t hangText="generated_ts"><vspace blankLines="0" /> 
                 The time at which the incoming message group was generated
                 by the sending AMP Agent.
              </t>
              
              <t hangText="state"><vspace blankLines="0" /> 
                 The current state of the incoming message group. This state
                 provides a contention-avoidance mechanism between
                 an application and an AMP Manager. This is a foreign key
                 that corresponds to the data_id in the data_types table.     
              </t>
              
              <t hangText="agent_id"><vspace blankLines="0" /> 
                 The identifier of the Agent sending this incoming message
                 group. This is a foreign key that corresponds to the registry_id
                 in the registered_agents table.                
              </t>
                            
           </list>
        </t>        
     </section>
      
   </section>

   <section title="Compound Data Types" toc="default">
    <section title="TNVC Support" toc="default">
      <section title="Type Name Value Collection - tnvc" toc="default">
<t>
  The tnvc table is a group of tnv collections.
        <figure align="center" title="tnvc" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+----------+------------------+------+-----+---------+-----------+
| Field    | Type             | Null | Key | Default | Extra     |
+----------+------------------+------+-----+---------+-----------+
| tnvc_id  | int(10) unsigned | NO   | PRI |         | auto_incr |
| order    | int(10) unsigned | NO   | UNI |         |           |
| name     | int(10) unsigned | YES  |     |         |           |
| value    | int(10) unsigned | NO   | MUL |         |           |
+----------+------------------+------+-----+---------+-----------+

</artwork>
</figure>

<list hangIndent="8" style="hanging">
  <t hangText="tnvc_id"><vspace blankLines="0" /> 
      The identifier of the TNV collection. This is a foreign key that
      corresponds to the tnvc_id in the tnvc_set table.               
  </t>

  <t hangText="order"><vspace blankLines="0" /> 
      The order of the tnvc in the set.               
  </t>

  <t hangText="name"><vspace blankLines="0" /> 
      The name of the tnvc.               
  </t>

  <t hangText="value"><vspace blankLines="0" /> 
      The value of the tnvc. This is a foreign key that corresponds
      to the data_id in the data_set table.               
  </t>
</list>
</t>
      </section>

          <section title="Type Name Value Collection Set - tnvc_set" toc="default">
            <t>
              The tnvc_set table provides the information of
              a TNV (Type-Name-Value) collection that describes
              data values in the AMM.

            <figure align="center" title="tnv_collection" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+----------+-----------------+------+-----+---------+-----------+
| Field    | Type            | Null | Key | Default | Extra     |
+----------+-----------------+------+-----+---------+-----------+
| tnvc_id  | int(10) unsigned| NO   | PRI | NULL    | auto_incr |
| comment  | varchar(255)    | NO   |     |         |           |
+----------+-----------------+------+-----+---------+-----------+

              </artwork>
            </figure>

<list hangIndent="8" style="hanging">
  <t hangText="tnvc_id"><vspace blankLines="0" /> 
      The identifier of the TNV collection. This is a primary key. 
  </t>
  <t hangText="comment"><vspace blankLines="0" /> 
      This is the description of the tnvc set. 
  </t>
  </list> 
  </t>  
  </section>
</section>
<section title="Expression Support">
  <section title="Expression Set - expression_set" toc="default">
    <t>
      The expression_set table shows the id of the expression as well as
      whether it is true or false. This table is a collection of expressions.

            <figure align="center" title="expression_set" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+---------+------------------+------+-----+---------+-----------+
| Field   | Type             | Null | Key | Default | Extra     |
+---------+------------------+------+-----+---------+-----------+
| expr_id | int(10) unsigned | NO   | PRI | NULL    | auto_incr |
| comment | varchar(255)     | NO   |     |         |           |
+---------+------------------+------+-----+---------+-----------+

              </artwork>
            </figure>

<list hangIndent="8" style="hanging">
  <t hangText="expr_id"><vspace blankLines="0" /> 
      The identifier of the expression. This is a primary key. 
  </t>

  <t hangText="comment"><vspace blankLines="0" /> 
      This is the description of the expression. 
  </t>
  </list>
  </t>   
  </section>

  <section title="Individual Expression - expression" toc="default">
    <t>
      An expression is an AC in which a series of items are ordered so as
      to produce a valid post-fix mathematical expression. This table
      contains all of the information that are included in each expression.

            <figure align="center" title="expression" suppress-title="false">               
              <artwork align="center" xml:space="preserve">
+-----------+------------------+------+-----+---------+-----------+
| Field     | Type             | Null | Key | Default | Extra     |
+-----------+------------------+------+-----+---------+-----------+
| expr_id   | int(10) unsigned | NO   | PRI | NULL    | auto_incr |
| order_num | int(10) unsigned | NO   | UNI | NULL    |           |
| ari_id    | int(10) unsigned | NO   | MUL | NULL    |           |
+-----------+------------------+------+-----+---------+-----------+

              </artwork>
            </figure>

<list hangIndent="8" style="hanging">
  <t hangText="expr_id"><vspace blankLines="0" /> 
      The identifier of the expression. This is a foreign key that corresponds
      to the expr_id in the expression_set table. 
  </t>

  <t hangText="order_num"><vspace blankLines="0" /> 
    The 0-based order of this entry in the encapsulating collection.                 
  </t>

  <t hangText="ari_id"><vspace blankLines="0" /> 
    This is the ari id. This is a foreign key that corresponds to the ari_id in the
    ari_definition table.                 
  </t>
  </list>  
  </t> 
  </section> 
  </section>
</section>

  
       
   <section anchor="IANA" title="IANA Considerations" toc="default">
   	<t>
			At this time, this schema definition has no fields registered by IANA.
	  	</t>
   </section>
   
   <section anchor="Security" title="Security Considerations" toc="default">
      <t>
         Security considerations are outside of the scope of this document.
      </t>
   </section>
  </middle>
  
  <!--  *****BACK MATTER ***** -->
  <back>
    <references title="Informative References">
      
       <?rfc include="reference.I-D.draft-birrane-dtn-ama-07"?>

    </references>
  
      <references title="Normative References">
         &RFC2119;     
         
          <?rfc include="reference.I-D.draft-birrane-dtn-adm-02"?>
          <?rfc include="reference.I-D.draft-birrane-dtn-amp-04"?>
      </references>
  
      
   <section anchor="contr" title="Acknowledgements">
      <t>
         The following participants contributed technical material, use cases, 
         and useful thoughts on the overall approach to this database 
         specification: Leor Bleir of the NASA Goddard Space Flight Center, 
         Michael Deschu and Shane Knudsen of Hammers Company, Inc. on behalf of
         the NASA Goddard Space Flight Center, and Paul Swencon of
         ASRC Space And Defense on behalf of the NASA Goddard Space Flight Center. 
      </t>
   </section>
      
  </back>
</rfc>