home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2552.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  65.4 KB  |  1,684 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          M. Blinov
  8. Request for Comments: 2552                                   M. Bessonov
  9. Category: Informational                                     C. Clissmann
  10.                                                            Teltec UCD-CS
  11.                                                                  Ireland
  12.                                                               April 1999
  13.  
  14.                 Architecture for Information Brokerage
  15.                         in the ACTS Project GAIA
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  It does
  20.    not specify an Internet standard of any kind.  Distribution of this
  21.    memo is unlimited.
  22.  
  23. Copyright Notice
  24.  
  25.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  26.  
  27. Abstract
  28.  
  29.    This memo introduces a domain and supplier independent generic
  30.    architecture for information brokerage, designed as part of the ACTS
  31.    project GAIA (Generic Architecture for Information Availability).
  32.  
  33. 1. Introduction
  34.  
  35.    Today a huge number of goods and services are offered on the
  36.    electronic market by a large, and ever-increasing, number of
  37.    suppliers.  However, there is still no efficient way for a customer
  38.    to find a product or information, he/she is interested in and a
  39.    supplier that can provide that product.  Customers and suppliers
  40.    already can not deal with the quantity of available information by
  41.    themselves.  The high heterogeneity of existing protocols, formats,
  42.    and underlying networks also limits development of the electronic
  43.    market.
  44.  
  45.    This results in a demand for brokerage systems that can work as
  46.    intermediary entities between customers and content suppliers.
  47.    Brokerage systems assist a customer during the trading process and
  48.    hide the heterogeneity and distribution of information from the
  49.    customer.  The design of domain and supplier independent generic
  50.    architecture for such brokerage systems is an objective of the
  51.    project GAIA (Generic Architecture for Information Availability).
  52.    GAIA received part funding from the EU ACTS programme for Research
  53.    and Technological Development.  The GAIA brokerage system allows a
  54.    customer to
  55.  
  56.  
  57.  
  58. Blinov, et al.                                                  [Page 1]
  59.  
  60. RFC 2552                          GAIA                        April 1999
  61.  
  62.  
  63.    - search for a particular "product" (information, content or
  64.      services) that he/she is interested in
  65.    - locate the product, i.e. find supplier(s) from whom the product is
  66.      available
  67.    - order the product from the supplier
  68.    - receive delivery of the product by digital means
  69.  
  70.    All these actions are carried out by the broker in response to
  71.    requests from the customer.  Broker services are accessible to the
  72.    customer through the unified user interface.  The customer system
  73.    does not have to support all the protocols involved in the trading
  74.    process.
  75.  
  76.    Full specification of the GAIA Architecture is available in the GAIA
  77.    Standard [1].  The GAIA Standard includes a description of the GAIA
  78.    Reference Model, GAIA Functional Architecture, GAIA Standard
  79.    Profiles, and specification of the GAIA interfaces.
  80.  
  81.    This memo does not aim to include the whole text of the GAIA
  82.    Standard, but to present the basic ideas and concepts of this
  83.    standard.
  84.  
  85.    The structure of this memo follows the structure of the GAIA
  86.    Standard:
  87.  
  88.    1.  The GAIA Reference Model provides a common basis for the
  89.        description and specification of brokerage systems, including the
  90.        GAIA system.
  91.  
  92.    2.  The GAIA Functional Architecture defines functional elements of
  93.        the GAIA Broker, their roles and relationships.
  94.  
  95.    3.  The GAIA Brokerage System Interfaces describes internal and
  96.        external interfaces of the GAIA brokerage system.
  97.  
  98.    4.  The GAIA Standard Profiles specifies mandatory and optional
  99.        profiles to which brokerage systems may conform.
  100.  
  101. 2.  The GAIA Reference Model
  102.  
  103.    The Generic Architecture for Information Availability (GAIA)
  104.    Reference Model outlines the operations and actors involved in
  105.    finding, ordering, and delivering physical and digital objects and
  106.    services ("Products") in a global brokered distributed information
  107.    environment.  It provides an overall view of the GAIA environment,
  108.    and illustrates the respective roles of and relationships between its
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Blinov, et al.                                                  [Page 2]
  115.  
  116. RFC 2552                          GAIA                        April 1999
  117.  
  118.  
  119.    components.  Further work on standards and frameworks for individual
  120.    components of the GAIA environment uses the model and terminology
  121.    provided by the Reference Model.
  122.  
  123.    The GAIA environment is a collection of actors and functions that are
  124.    combined to support a procedure for information and services
  125.    discovery, order, and delivery.  The actors play roles in the
  126.    procedure, including initiation and execution of the Actions which
  127.    are combined to make up the overall transaction.  The GAIA
  128.    architecture provides a standardised and widely applicable framework
  129.    for the provision and implementation of the brokered search and
  130.    retrieve applications in a large-scale networked environment.
  131.  
  132. 2.1.  GAIA Roles
  133.  
  134.    The GAIA model considers three principal roles that can be played by
  135.    the GAIA actors.  These are the Customer, the Broker and the
  136.    Supplier.  These Roles are shown in Figure 1 below.  It also
  137.    considers a further class of active entities who play supporting
  138.    roles in the Actions.  This latter class is known as GAIA "Helpers"
  139.    and includes, for example, authentication and payment.  The actors
  140.    are organisations and individuals in the supply chain.  Every GAIA
  141.    actor plays at least one role at any given time.
  142.  
  143. 2.1.1.  The Customer
  144.  
  145.    The aim of the Customer is to obtain some Products or information
  146.    about some Products.  The Customer role initiates the GAIA
  147.    transaction by requesting one or more GAIA Actions, and receives the
  148.    results of the transaction.  The Customer may deal with actors
  149.    playing either of the other two roles: the Broker or the Supplier.
  150.    These actors may themselves play the role of the Customer while
  151.    requesting further services from other Brokers.
  152.  
  153. 2.1.2.  The Broker
  154.  
  155.    The Broker provides brokerage services to the Customer and the
  156.    Supplier.  It responds to requests from the Customer to provide
  157.    Products, or information about Products.  The Products that the
  158.    Broker supplies to the Customer may originate from one or more
  159.    Suppliers and/or Brokers.  The Broker's primary role is to act as a
  160.    collector and collator of information from a number of different
  161.    Suppliers, and to supply this information to the Customer, thus
  162.    obviating the need for the Customer to deal with a variety of
  163.    Suppliers.  A Broker can also be considered to act on behalf of a
  164.    Supplier, distributing information about the Products available.  The
  165.    actor playing the role of the Broker may play the role of a Supplier
  166.  
  167.  
  168.  
  169.  
  170. Blinov, et al.                                                  [Page 3]
  171.  
  172. RFC 2552                          GAIA                        April 1999
  173.  
  174.  
  175.    to a Customer or other Broker at the same time.  The Broker may play
  176.    the role of a Customer while interacting with another Broker or with
  177.    a Supplier.
  178.  
  179. 2.1.3.  The Supplier
  180.  
  181.    The Supplier is the source of the Product supplied to the Customer.
  182.    The Supplier provides the Broker with information about the Product
  183.    that it can supply.  The Supplier may supply its Product directly to
  184.    the Customer, or to the Broker for forwarding to the Customer.  An
  185.    actor playing the role of a Supplier may also play the role of a
  186.    Broker.  A Supplier may deal with a large number of Brokers and
  187.    Customers over a number of GAIA transactions.
  188.  
  189. 2.1.4.  Helpers
  190.  
  191.    A Helper is an application layer entity playing a supporting role in
  192.    a GAIA transaction.  Helpers provide some service needed in the
  193.    supply chain, but outside the core functionality of the Broker.
  194.    Examples include a global directory service, payment service, or
  195.    authentication service.
  196.  
  197.    The authentication Helper is concerned with facilitating the
  198.    authentication of one actor to another.
  199.  
  200.    The payment Helper is concerned with supporting a mechanism for
  201.    payment to one actor by another.
  202.  
  203.    In any given GAIA transaction, there will be one or more Customers
  204.    (usually one), one or more Brokers, and one or more Suppliers.  A
  205.    description of the Product sought by the Customer is provided by the
  206.    Customer to the Broker.  The Broker may involve other Brokers in the
  207.    search for the Product.  When a Supplier of the Product is discovered
  208.    by the Broker, this information is included in the response of the
  209.    Broker to the Customer.  During the course of the Action, it may be
  210.    necessary to call upon the services of one or more Helpers.
  211.  
  212. 2.2.  GAIA Actions
  213.  
  214.    Each GAIA transaction is made up of one or more Actions.  These
  215.    Actions are requests by the Customer to the Broker or the Supplier to
  216.    carry out some operation and to return a response.  Four Actions are
  217.    defined:
  218.  
  219.    - Search
  220.    - Locate
  221.    - Order
  222.    - Deliver
  223.  
  224.  
  225.  
  226. Blinov, et al.                                                  [Page 4]
  227.  
  228. RFC 2552                          GAIA                        April 1999
  229.  
  230.  
  231.    These Actions are shown in Figure 1.
  232.  
  233.    +--------+    .   .    +--------+    .   .    +-----------+
  234.    |        |-- Search -->|        |-- Search -->|           |+
  235.    |        |    :   :    |        |    :   :    |           ||
  236.    |        |-- Locate -->|        |-- Locate -->|           ||
  237.    |Customer|    :   :    | Broker |    :   :    |Supplier(s)||
  238.    |        |-- Order --->|        |-- Order --->|           ||
  239.    |        |    :   :    |        |    :   :    |           ||
  240.    |        |<- Deliver --|        |<- Deliver --|           ||
  241.    +--------+    :   :    +--------+    :   :    +-----------+|
  242.                  :   :                  :   :     +-----------+
  243.                 Helpers                Helpers
  244.              <Authentication> <Payment> <Security>
  245.  
  246.    Figure 1 GAIA Roles and Actions
  247.  
  248. 2.2.1.  Search
  249.  
  250.    The Search Action is carried out when the Customer asks the Broker to
  251.    find some information on its behalf.  To do this, the Customer
  252.    provides the Broker with some description of the Product it requires.
  253.    On the basis of this description, the Broker carries out a search on
  254.    behalf of the Customer and returns the result.  The result of a
  255.    Search Action is a set of unique identifiers referencing the Products
  256.    matching the description provided by the Customer.
  257.  
  258. 2.2.2.  Locate
  259.  
  260.    The Locate Action is carried out when the Customer asks the Broker to
  261.    provide it with information regarding the location and source of some
  262.    Product.  To allow the Broker to do this, the Customer provides an
  263.    unambiguous identification of the Product, which may be the result of
  264.    a Search Action.  The Broker returns information to the Customer
  265.    about a source or sources for the Product.  These data include the
  266.    Terms of Availability information such as available methods of
  267.    delivery, time of delivery, costs, etc.  However, this information
  268.    can not be considered final since some special terms and conditions
  269.    may apply, e.g. discounts for some categories of Customers.  The
  270.    final version of the Terms of Availability is established during the
  271.    negotiation phase of the Order Action.
  272.  
  273. 2.2.3.  Order
  274.  
  275.    The Order Action is carried out when the Customer asks the Broker to
  276.    obtain a Product on its behalf, or asks the Supplier to sell the
  277.    Product directly to the Customer.  To enable an Order, the Customer
  278.    provides the Broker/Supplier with Product source information, which
  279.  
  280.  
  281.  
  282. Blinov, et al.                                                  [Page 5]
  283.  
  284. RFC 2552                          GAIA                        April 1999
  285.  
  286.  
  287.    may be a result of a Locate Action.  The Order Action consists of a
  288.    negotiation phase and (possibly) a purchase phase.  During the
  289.    negotiation phase the Customer obtains the quotation that contains
  290.    the final version of the Terms of Availability for the (batch of)
  291.    Products he is considering purchasing.  If the Customer finds these
  292.    conditions satisfactory, he commits to the purchase.  Alternatively,
  293.    if the Broker or Supplier supports telepresence services for the
  294.    human interaction with the Supplier or Broker representatives, these
  295.    may be used during the negotiations.
  296.  
  297. 2.2.4.  Deliver
  298.  
  299.    The Deliver Action is carried out when the Broker provides the
  300.    Customer with some requested Product.  The Product may be
  301.    information, some physical object, or metadata.  The Deliver Action
  302.    may be in response to an Order Action, a Search Action, or a Locate
  303.    Action.
  304.  
  305.    While the Actions presented in this section may logically be taken to
  306.    form an integrated sequence, this is not necessarily the case.
  307.    Actions may take place independently, rather than as a part of a
  308.    four-Action whole.  For example, Order and Deliver Actions may occur
  309.    on the basis of information obtained by the Customer using some other
  310.    mechanism than GAIA Search and Locate Actions.
  311.  
  312. 2.3.  GAIA Helper Events
  313.  
  314.    During any of the GAIA Actions outlined above, it may be necessary to
  315.    carry out some supporting activity.  These activities are called GAIA
  316.    Helper events.  They include, for example, authentication and
  317.    payment.  The Helper entities are involved in the GAIA events to
  318.    provide services, additional to the GAIA Actions, to the GAIA actors.
  319.  
  320.    Authentication
  321.  
  322.    In order to verify the identity of one GAIA actor to another, an
  323.    authentication exchange may need to take place.  This may occur
  324.    during any of the GAIA Actions.  The manner or method of
  325.    authentication is outside the scope of this document.
  326.  
  327.    Payment
  328.  
  329.    It may be necessary for payment to take place during a GAIA
  330.    transaction.  In this situation, one GAIA actor pays one or more
  331.    other GAIA actors.  The manner or method of payment is outside the
  332.    scope of this document.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Blinov, et al.                                                  [Page 6]
  339.  
  340. RFC 2552                          GAIA                        April 1999
  341.  
  342.  
  343.    Security
  344.  
  345.    As part of any GAIA Action, it may be necessary to carry out some
  346.    security operations, such as encryption of data, verification of
  347.    source and content integrity of Product, or digital signature of some
  348.    data entity or entities.  The particular security services and
  349.    mechanisms which may be required, or the manner in which they may be
  350.    provided, is outside the scope of this document.
  351.  
  352. 3.  The GAIA Functional Architecture
  353.  
  354. 3.1.  The Concept
  355.  
  356.    The GAIA Functional Architecture decomposes the overall functionality
  357.    of the GAIA Broker into a number of components and describes the
  358.    roles and relationships of these components, and the manner in which
  359.    they interoperate.
  360.  
  361.    To work in a heterogeneous environment the GAIA Functional
  362.    Architecture introduces three levels of abstract elements of the
  363.    Broker: the Kernel, Functional Unit Managers (FUMs), and Functional
  364.    Units (FUs) (see Figure 2).
  365.  
  366.        GAIA Broker:
  367.        ------------
  368.                       [  Kernel  ]                Kernel
  369.                         /       \                 level
  370.                        /         \
  371.         [Functional Unit]     [Functional Unit]   Technology-independent
  372.         [    Manager    ]     [    Manager    ]   action-dependent
  373.              /    \                 /    \        level
  374.             /      \               /      \
  375.     [Functional][Functional] [Functional][Functional]  Technology
  376.     [Unit      ][Unit      ] [Unit      ][Unit      ]  dependent
  377.                                                        level
  378.     Figure 2 Levels of the architecture
  379.  
  380.    Functional Units are the technology dependent parts of the
  381.    architecture.  They perform required transactions in terms of a
  382.    particular protocol.  All FUs are covered by a technology independent
  383.    interface.  FUs are grouped according to the trading action they
  384.    participate in, e.g. search FUs or locate FUs.  Each group of FUs is
  385.    governed by the corresponding Functional Unit Manager.
  386.  
  387.    Functional Unit Managers contain technology independent functions for
  388.    particular actions.  To use a particular technology an FUM uses the
  389.    services of attached FUs.  There may be several FUs associated with
  390.    an FUM, allowing the FUM to operate in different technology contexts.
  391.  
  392.  
  393.  
  394. Blinov, et al.                                                  [Page 7]
  395.  
  396. RFC 2552                          GAIA                        April 1999
  397.  
  398.  
  399.    There is one FUM in the system for every area of functionality, e.g.
  400.    search, locate, and order.  The Kernel is responsible for managing
  401.    the activity of different FUMs (corresponding to different actions)
  402.    and synchronising events between them.
  403.  
  404.    The GAIA Functional Architecture establishes relationships between
  405.    the existing technologies (standards and protocols) that are combined
  406.    in the GAIA Standard, in the context of a brokerage system.  It is to
  407.    be expected that new technologies will evolve which will be viable
  408.    alternatives to those selected.  The abstract and modular nature of
  409.    the Functional Architecture allows the replacement of one technology
  410.    with a new one without disruption to the rest of the brokerage
  411.    system.
  412.  
  413. 3.2.  Functional Units
  414.  
  415.    The brokerage system provides a number of services to its users.
  416.    These services are supported by the functions of the brokerage
  417.    system.  These include, for example,
  418.  
  419.    - searching
  420.    - ordering
  421.    - payment
  422.  
  423.    Each of these functions can be provided by a number of different
  424.    candidate technologies.  However, the operations that are required to
  425.    be carried out remain the same.  Regardless of the selected
  426.    technologies, the functional requirements do not change.  The
  427.    required operations are described in terms of abstract primitives,
  428.    which can be mapped to the protocol instructions of the technology
  429.    selected to support the function.  A mapping component, called a
  430.    Functional Unit (FU), is defined for each candidate technology, and
  431.    converts calls to abstract primitives into protocol instructions.
  432.    The FU acts as an adaptor between its particular technology and the
  433.    rest of the brokerage system.
  434.  
  435.    Functional Units are defined for each candidate technology that can
  436.    be used to fulfil a particular functional need of the brokerage
  437.    system.  A Functional Unit accepts abstract primitive invocations,
  438.    and maps them to calls to the particular technology to which it is
  439.    dedicated.  The results of these calls are translated into the
  440.    corresponding abstract primitives and returned by the FU, as shown in
  441.    Figure 3.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Blinov, et al.                                                  [Page 8]
  451.  
  452. RFC 2552                          GAIA                        April 1999
  453.  
  454.  
  455.              * The rest of the Broker *
  456.                     ^
  457.                     |  -abstract primitives
  458.                     v
  459.                  +------------+
  460.                  | Functional |
  461.                  |    Unit    |
  462.                  +------------+
  463.                     ^
  464.                     |  -technology-specific commands
  465.                     v
  466.              * Technology functions *
  467.  
  468.    Figure 3 GAIA Functional Unit
  469.  
  470. 3.3.  Functional Unit Managers
  471.  
  472.    As noted above, a number of different candidate technologies can be
  473.    used to fulfil a particular functional requirement of the brokerage
  474.    system.  Depending on the details of the GAIA transaction (underlying
  475.    network, Customer system capabilities, etc.), different technologies
  476.    may be more useful during different transactions.  As a result, each
  477.    candidate technology has its own Functional Unit, which is invoked
  478.    when that particular technology is required.
  479.  
  480.    A number of different Functional Units can exist which fulfil the
  481.    same functional requirement of the brokerage system.  To select the
  482.    most appropriate FU (and technology), the brokerage system needs to
  483.    know which is the most useful at any particular time; in general this
  484.    is the technology supported by the target Supplier system.  This is
  485.    the responsibility of the Functional Unit Manager, or FUM.  Each
  486.    function of the brokerage system has a single FUM, which is invoked
  487.    using abstract primitives by the Broker Kernel.  This FUM selects the
  488.    most appropriate of the candidate technologies, and calls the
  489.    corresponding FU (see Figure 4).
  490.  
  491.    The interface between the FUM and the corresponding FUs is defined
  492.    for every FUM in an open, platform independent, and programming
  493.    language independent manner.  These interfaces do not depend on any
  494.    particular technology.  It allows for configuring the set of
  495.    technologies supported by the Broker, by attaching different subsets
  496.    of FUs.  If a new technology is to be supported by a Broker, a new FU
  497.    implementing this technology can be created according to the
  498.    specification of the interface, and attached to the corresponding
  499.    FUM.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Blinov, et al.                                                  [Page 9]
  507.  
  508. RFC 2552                          GAIA                        April 1999
  509.  
  510.  
  511.              +--------------------------------------+
  512.              |       Functional Unit Manager        |
  513.              +--------------------------------------+
  514.                     ^                       ^
  515.                     | -abstract primitives- |
  516.                     v                       v
  517.                +------------+        +------------+
  518.                | Functional |        | Functional |
  519.                |    Unit    |        |    Unit    |
  520.                +------------+        +------------+
  521.                 ^                                ^
  522.                 | -technology-specific commands- |
  523.                 v                                v
  524.               * Technology *          * Technology *
  525.               * functions  *          * functions  *
  526.  
  527.    Figure 4 Functional Unit Manager
  528.  
  529. 3.4.  The Kernel
  530.  
  531.    The Kernel of the brokerage system acts as a bus for the transmission
  532.    of abstract primitives between FUMs.  Each FUM imports a set of
  533.    abstract primitives representing those services which the FUM expects
  534.    to receive from some other part of the system.  The services that the
  535.    FUM is prepared to provide to other elements of the brokerage system
  536.    are presented in the form of exported abstract primitives.  All these
  537.    abstract primitives are imported from, and exported to, the Kernel
  538.    (see Figure 5).
  539.  
  540.    The Kernel is also responsible for synchronisation of different
  541.    actions within a transaction and for maintaining a common context
  542.    between actions.
  543.  
  544.              +-------------------------------------+
  545.              |           Broker Kernel             |
  546.              +-------------------------------------+
  547.                   ^            ^              ^
  548.                   | -abstract- | -primitives- |
  549.                   v            v              v
  550.               +-------+     +-------+     +-------+
  551.               |  FUM  |     |  FUM  |     |  FUM  |
  552.               +-------+     +-------+     +-------+
  553.  
  554.    Figure 5 Broker Kernel
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Blinov, et al.                                                 [Page 10]
  563.  
  564. RFC 2552                          GAIA                        April 1999
  565.  
  566.  
  567. 3.5.  Description of FUMs
  568.  
  569.    The core activities of the brokerage system include:
  570.  
  571.    1.  searching for Products that fit a user description
  572.    2.  sourcing Products the identification of which is known
  573.    3.  allowing users to order Products
  574.    4.  delivering information in item format
  575.    5.  delivering information as a continuous media stream
  576.    6.  providing a user interface to the brokerage services
  577.    7.  alerting users as to the availability of information
  578.    8.  interacting with external directory services
  579.    9.  authentication of other actors
  580.    10.  payment operations
  581.  
  582.    Each of these activities is carried out by the corresponding FUM as
  583.    described below and shown in Figure 6.
  584.  
  585.    Search FUM
  586.  
  587.    The Search FUM accepts requests to carry out a search for Products
  588.    that fit a particular user description.  It returns lists of
  589.    identifiers of Products that fit the description.
  590.  
  591.    Locate FUM
  592.  
  593.    The Locate FUM accepts Product identifiers and discovers where they
  594.    may be obtained.  It returns lists of Suppliers and locations for the
  595.    Product.
  596.  
  597.    Order FUM
  598.  
  599.    The Order FUM manages negotiations between a Customer and a Supplier
  600.    in order that agreement may be reached on the terms of availability
  601.    of a particular Product or group of Products.  Following the
  602.    negotiation phase, the Order FUM accepts purchase commitments from
  603.    the Customer and forwards them to the Supplier.  It returns a
  604.    notification of the status of the Order Action.
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Blinov, et al.                                                 [Page 11]
  619.  
  620. RFC 2552                          GAIA                        April 1999
  621.  
  622.  
  623.                         The GAIA Broker:
  624.                         ----------------
  625.    (Customer))   (Alerting))  (  DS   ))  (Auth))  (Payment))
  626.    (   FUs  ))   (   FUs  ))  (  FUs  ))  ( FUs))  (  FUs  ))
  627.    (e.g.HTTP))   (e.g. SMS))  (eg LDAP))  (    ))  (e.g.SET))
  628.        \/            \/           \/        \/        \/
  629.    [Customer]     [Alerting]    [ DS  ]  [ Auth ]  [Payment]
  630.    [  FUM   ]     [  FUM   ]    [ FUM ]  [  FUM ]  [  FUM  ]
  631.        |              |            |         |         |
  632.     +----------------------------------------------------------+
  633.     |                  Broker Kernel                           |
  634.     +----------------------------------------------------------+
  635.        |             |            |            |            |
  636.    [ Search ]    [ Locate ]    [ Order ]   [ Stream ]   [Discrete]
  637.    [  FUM   ]    [  FUM   ]    [  FUM  ]   [Delivery]   [Delivery]
  638.    [        ]    [        ]    [       ]   [  FUM   ]   [  FUM   ]
  639.        /\            /\           /\           /\           /\
  640.    ( Search  ))  ( Locate  ))  (  Order   ))  ( SD   ))  ( DD   ))
  641.    (   FUs   ))  (   FUs   ))  (  FUs     ))  ( FUs  ))  ( FUs  ))
  642.    (eg Z39.50))  (eg Z39.50))  (eg ISO ILL))  (eg RTP))  (eg FTP))
  643.  
  644.    Figure 6 GAIA Functional Architecture
  645.  
  646.  
  647.    Discrete Delivery FUM
  648.  
  649.    The Discrete Delivery FUM manages the delivery of discrete items to
  650.    the Customer.
  651.  
  652.    Stream Delivery FUM
  653.  
  654.    The Stream Delivery FUM manages the delivery of real-time multimedia
  655.    data streams to the Customer.
  656.  
  657.    Customer FUM
  658.  
  659.    The Customer FUM provides an interface to support the Customer's
  660.    systems interaction with the brokerage system.
  661.  
  662.    Alerting FUM
  663.  
  664.    The Alerting FUM notifies Customers about changes that may interest
  665.    them.
  666.  
  667.    Directory Services FUM
  668.  
  669.    The Directory Services FUM provides an interface between an external
  670.    directory service and the brokerage system.
  671.  
  672.  
  673.  
  674. Blinov, et al.                                                 [Page 12]
  675.  
  676. RFC 2552                          GAIA                        April 1999
  677.  
  678.  
  679.    Authentication FUM
  680.  
  681.    The Authentication FUM provides a mechanism that allows a user to
  682.    prove his identity to the brokerage system.
  683.  
  684.    Payment FUM
  685.  
  686.    The Payment FUM provides a mechanism for payment from one actor to
  687.    another.
  688.  
  689. 4.  GAIA Brokerage System Interfaces
  690.  
  691.    This Chapter describes the internal and external interfaces of the
  692.    GAIA brokerage system.
  693.  
  694. 4.1.  Internal Interfaces
  695.  
  696.    The definition of communication between functional components within
  697.    the GAIA Broker is based on the OMG CORBA model [2].  Interfaces
  698.    between components are defined in the IDL language specified by OMG.
  699.    Interface calls are passed between components by the Object Request
  700.    Broker (ORB).
  701.  
  702.    The advantage of this approach is that the specifications of the
  703.    interfaces are platform and programming language independent.  These
  704.    interfaces can be implemented using different programming languages
  705.    on different platforms.  All necessary conversions during interface
  706.    invocations are transparently performed by an ORB.  The CORBA model
  707.    also allows installing different functional components of the GAIA
  708.    Broker on different computers connected by a network.  Interface
  709.    calls will be transferred over the network by an ORB transparently
  710.    for the application.
  711.  
  712.    The specification of the interfaces between the Kernel and FUMs and
  713.    between each FUM and corresponding FUs is presented in the GAIA
  714.    Standard [1].
  715.  
  716. 4.2.  External protocols
  717.  
  718.    The GAIA Broker can use existing protocols to communicate with other
  719.    actors.  For example, it can use HTTP for interactions with
  720.    Customers, Z39.50 for search, etc.  As described in the GAIA
  721.    Functional Architecture, support for particular technologies is
  722.    provided by FUs.  A set of supported protocols can be extended by
  723.    attaching the corresponding new FUs to a Broker.  The GAIA Broker can
  724.    support several protocols for each action.  The FUMs will select the
  725.    most appropriate protocol for a transaction.  The more protocols
  726.    supported by the Broker, the better service it can provide to
  727.  
  728.  
  729.  
  730. Blinov, et al.                                                 [Page 13]
  731.  
  732. RFC 2552                          GAIA                        April 1999
  733.  
  734.  
  735.    Customers and Suppliers.
  736.  
  737.    The GAIA Standard does not limit the set of protocols supported by
  738.    the Broker.  However, for the purpose of interoperability, it
  739.    specifies several GAIA profiles.  These profiles define a common
  740.    subset of protocols (and a common range of protocol parameters) that
  741.    Brokers are encouraged to support in order to make communication
  742.    between GAIA Brokers, and with GAIA-aware Suppliers and Customers,
  743.    possible.
  744.  
  745.    Existing protocols are not the only way to contact the GAIA Broker.
  746.    The GAIA interfaces have been designed as a generalisation of
  747.    existing interfaces and protocols, so they provide more functionality
  748.    than any particular protocol.  To give access to the full
  749.    functionality of the GAIA Broker, the GAIA Standard allows users
  750.    (Customers and other Brokers) to directly use the CORBA-defined
  751.    Customer interface of the GAIA Broker (interface between the Customer
  752.    FUM and FUs) as shown in Figure 7.  In this case, the Customer system
  753.    gets access to the Customer interface of the Broker using the service
  754.    of an underlying ORB, and can request operations by calling the
  755.    corresponding methods of the interface.  The Customer interface of
  756.    the GAIA Broker is specified in the GAIA Standard [1].
  757.  
  758.    Where Customer and Supplier systems are not CORBA-aware, they can
  759.    communicate with a GAIA Broker using existing protocols.  If,
  760.    however, they can use the service of an ORB, they are encouraged to
  761.    communicate with a Broker by connecting to its Customer interface.
  762.    This method allows for avoiding convergence between a particular
  763.    protocol and the GAIA interface.  The former method makes
  764.    interactions with all existing types of Customers and Suppliers
  765.    possible using existing and widespread protocols.  The later method
  766.    has been designed to achieve maximum functionality by using native
  767.    GAIA methods for communication with Customers and Suppliers.
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Blinov, et al.                                                 [Page 14]
  787.  
  788. RFC 2552                          GAIA                        April 1999
  789.  
  790.  
  791.                               +----------------+
  792.                               |Broker          |
  793.                               |                |
  794.                               |   --------     |
  795.       +-----------+           |  [ Kernel ]    |
  796.       |  Broker   |           |   --------     |
  797.       |    or     |           |  [Customer]    |
  798.       | Customer  |           |  [  FUM   ]    |
  799.       |           |           |  ========== <-GAIA Customer
  800.       |        *  |           |  *       *     | \interface
  801.       | { O R B *}* * * * * * *{* O  R  B * }  |
  802.       +-----------+    iiop   |            *   |         +----------+
  803.                               |     (Customer) |         | Customer |
  804.                               |     (   FU   ) |         |          |
  805.                               +------------I---+         +----I-----+
  806.                                             \      HTTP      /
  807.                                              - - -      - - -
  808.  
  809.       Figure 7 External protocols and the GAIA Customer interface
  810.  
  811. 5.  GAIA Standard Profiles
  812.  
  813.    The GAIA Standard defines a number of profiles, which a Broker may
  814.    support in order to achieve interoperability with other GAIA actors
  815.    (Customers, Suppliers and other Brokers).  The complexity of the
  816.    profile chosen by a Broker depends on the level and type of service
  817.    which the Broker wishes to deliver in a GAIA-conformant manner.  The
  818.    higher the level of service that a Broker provides to a Customer, and
  819.    the greater the length of the supply chain which the Broker wishes to
  820.    support, the more advanced the profile and/or the greater the number
  821.    of extension modules the Broker must support.
  822.  
  823. 5.1.  Supply Chains
  824.  
  825.    The GAIA profile definition approach is based on the possible types
  826.    of supply chain that a brokerage system can be a part of.
  827.  
  828.    The operations of a brokerage system can be broken into three
  829.    categories:
  830.  
  831.    - interactions with the Customer
  832.    - interactions with other Brokers
  833.    - interactions with Suppliers
  834.  
  835.    The first and last of these occur at the two ends of a supply chain,
  836.    while interbroker operations take place at other points in the chain.
  837.    The supply chain may take a number of different forms:
  838.  
  839.  
  840.  
  841.  
  842. Blinov, et al.                                                 [Page 15]
  843.  
  844. RFC 2552                          GAIA                        April 1999
  845.  
  846.  
  847.    - a minimal chain, where the Customer and the Broker are the ends of
  848.      the chain and there are no intervening links.  In this case, the
  849.      Broker plays the role of Supplier to the Customer.
  850.  
  851.    - a three-piece chain, where the Broker deals with the Customer and
  852.      the Supplier but not with any other Broker.
  853.  
  854.    - a longer chain, with one or more interbroker operations.
  855.  
  856.       Minimal Supply Chain:
  857.           +--------+         +-------------+
  858.           |Customer| <=====> | Broker      |
  859.           +--------+         |(as Supplier)|
  860.                              +-------------+
  861.       3-piece Supply Chain:
  862.           +--------+       +--------+       +--------+
  863.           |Customer| <===> | Broker | <===> |Supplier|
  864.           +--------+       +--------+       +--------+
  865.       Longer Supply Chain:
  866.           +--------+       +--------+   +--------+       +--------+
  867.           |Customer| <===> | Broker |<=>| Broker | <===> |Supplier|
  868.           +--------+       +--------+   +--------+       +--------+
  869.  
  870.       Figure 8 Supply Chains
  871.  
  872. 5.1.1.  Minimal Supply Chains
  873.  
  874.    As discussed in the GAIA Reference Model, a GAIA transaction is
  875.    composed of a number of actions, such as search, order, and delivery.
  876.    Each transaction is initiated by the Customer who makes a request to
  877.    the Broker.  In the event that the Broker is able to fulfil the
  878.    request, the transaction involves no other actors.
  879.  
  880.    In this simple case, the GAIA transaction involves the Customer and
  881.    the Broker.  The only protocol which needs to be standardised is that
  882.    between the Customer and the Broker.  This is specified in the GAIA
  883.    Standard Minimal profile below.
  884.  
  885. 5.1.2.  Longer Supply Chains
  886.  
  887.    In the event that the Broker is not able to fulfil a request, the
  888.    action may be propagated on to other Brokers, with the original
  889.    Broker playing the Customer role.  Each of these Brokers may in turn
  890.    propagate the request if they cannot fulfil it.
  891.  
  892.    Eventually, if the action is successful, a Supplier will be found who
  893.    can fulfil the request.  The supply chain is thus made up a single
  894.    Customer, one or more Suppliers, and one or more Brokers.
  895.  
  896.  
  897.  
  898. Blinov, et al.                                                 [Page 16]
  899.  
  900. RFC 2552                          GAIA                        April 1999
  901.  
  902.  
  903.    In order to propagate an action from one Broker to another, a
  904.    standardised communication protocol must be defined for broker-broker
  905.    interaction.  This is specified in the Basic profile, below.  This
  906.    profile is based on CORBA.
  907.  
  908.    Supplier and Brokers, however, are not obliged to support the Basic
  909.    profile of the GAIA Standard.  They may instead use another, more
  910.    traditional, protocol such as Z39.50 for discovery, or ISO ILL for
  911.    ordering.  The Extension Modules to the GAIA Standard specify the
  912.    profiles to be used for various brokerage functions.
  913.  
  914. 5.2.  Introduction to the GAIA Standard Profiles and Modules
  915.  
  916.    The profiles specified are
  917.  
  918.    - The Minimal profile, which is the very least to which a GAIA Broker
  919.      must conform
  920.    - The Basic Profile, which allows inter-broker communication
  921.    - A number of Extension Modules, which allow the Broker to provide
  922.      various services, and to interoperate with Suppliers, Brokers and
  923.      Customers using protocols specified in the modules
  924.    - A set of Interface Modules, that defines which particular
  925.      Functional Unit CORBA interfaces are supported by the Broker
  926.  
  927.    Each Broker must conform at least to the Minimal profile to provide a
  928.    web-based user interface.  In addition, to take part in inter-broker
  929.    communications, the Basic profile is recommended.  For interaction
  930.    with non-CORBA-aware entities, and for the use of advanced services,
  931.    there are other modules of the standard to which the Broker may
  932.    conform.  These are denoted "Extension Modules", and they
  933.    characterise the protocols and standards in a particular area of
  934.    functionality.  A Broker can choose an appropriate set of Extension
  935.    Modules to conform to according to the functionality it wishes to
  936.    achieve.
  937.  
  938.    The GAIA Standard specifies all interfaces between FUM and FUs for
  939.    the GAIA Broker.  However, it would be too much to require every
  940.    Broker to implement all of them.  The GAIA Standard decomposes all
  941.    interfaces into a number of Interface Modules.  A Broker can choose a
  942.    subset of Interface Modules that are more important in its area of
  943.    operation, and implement interfaces defined in these modules.  These
  944.    interfaces are important only inside the broker system and do not
  945.    play any role in communication with other GAIA actors.  However, a
  946.    declaration of supported interfaces is important for the
  947.    administrator to find the areas in which the functionality of the
  948.    Broker can be extended by attaching GAIA-conformant FUs.
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Blinov, et al.                                                 [Page 17]
  955.  
  956. RFC 2552                          GAIA                        April 1999
  957.  
  958.  
  959. 5.3.  Minimal Profile
  960.  
  961.    The minimum functionality that a Broker must support will allow it to
  962.    provide services to the Customer as a part of a minimal chain.  In
  963.    this case, what is required of the Broker is simply a user interface
  964.    for the Customer.  Any further operations take place within the
  965.    Broker, and so do not come within the scope of the standard.
  966.  
  967.    The Minimal profile requires the Broker to implement a user interface
  968.    based on the HTTP 1.1 protocol, defined in RFC 2068 [3], and HTML
  969.    2.0, defined in RFC 1866 [4].  It means that a Customer should be
  970.    able to access the basic functionality of the GAIA Broker by using a
  971.    HTTP 1.1 and HTML 2.0 conformant web-browser.
  972.  
  973.    It should be possible for Customers to locate a GAIA Broker.  Thus a
  974.    GAIA Broker should be registered in a Directory Service using a
  975.    schema specified in the GAIA Standard [1].
  976.  
  977.    +-------------------------------------------------+
  978.    | Minimal Profile                                 |
  979.    +------------------------+------------------------+
  980.    | Customer               | HTTP 1.1 (server),     |
  981.    |                        | HTML 2.0               |
  982.    +------------------------+------------------------+
  983.  
  984. 5.4.  Basic Profile
  985.  
  986.    While the minimal functionality is sufficient to allow a Broker to
  987.    function, an important aspect of any GAIA Broker functionality is
  988.    dealing with other Brokers.  The goal of the Basic profile is to
  989.    achieve federation between Brokers.  Every GAIA Broker can use the
  990.    service of other GAIA Brokers in order to fulfil a request of a
  991.    Customer.  That Broker in turn can use the service of the third GAIA
  992.    Broker.  So every request can be chained by several Brokers.  This
  993.    extends the abilities of every GAIA action (Search, Locate, Order,
  994.    etc.).  Chained transactions are particularly important in the
  995.    discovery phase of a transaction, where a Broker unable to fulfil a
  996.    particular information requirement passes on the search to another
  997.    Broker.
  998.  
  999.    The Basic profile requires the Broker to implement the GAIA Customer
  1000.    interface defined in terms of CORBA.  This interface is described in
  1001.    more detail in Section 4.2 above.  The Basic profile also requires
  1002.    the Broker to implement interface requestor procedures, i.e. to be
  1003.    able to connect to the Customer interfaces of other Brokers.  The ORB
  1004.    used by the Broker should be conformant to the CORBA 2.0
  1005.    specification [2] and use IIOP protocol for inter-ORB communications
  1006.    [2].
  1007.  
  1008.  
  1009.  
  1010. Blinov, et al.                                                 [Page 18]
  1011.  
  1012. RFC 2552                          GAIA                        April 1999
  1013.  
  1014.  
  1015.    A full specification of the GAIA Customer interface is presented in
  1016.    the GAIA Standard [1].
  1017.  
  1018.    A GAIA Broker should be able to find other Brokers and Suppliers.  It
  1019.    should also allow other participants to find it.  Thus a GAIA Broker
  1020.    should support a directory service.  The Basic profile includes a
  1021.    directory access protocol for this purpose.  The actual choice of
  1022.    protocol is not standardised, because the choice does not influence
  1023.    the success of the Broker's inter-operation with other Brokers.  The
  1024.    directory schema, which should be used, is specified in the GAIA
  1025.    Standard.
  1026.  
  1027.    The Basic profile suggested for a Broker to allow it to interoperate
  1028.    with other GAIA Brokers is as follows.
  1029.  
  1030.    +----------------------------------------------------------------+
  1031.    | Basic Profile                                                  |
  1032.    +------------------------+---------------------------------------+
  1033.    | Customer               | GAIA Customer interface/IIOP (server) |
  1034.    | Search and Locate      | GAIA Customer interface/IIOP (client) |
  1035.    |        (Discovery)     |                                       |
  1036.    | Order                  | GAIA Customer interface/IIOP (client) |
  1037.    | Directory              | Some directory access protocol,       |
  1038.    |                        | such as LDAP                          |
  1039.    +------------------------+---------------------------------------+
  1040.  
  1041. 5.5.  Extension Modules
  1042.  
  1043.    In order to allow Brokers to interoperate with other Brokers that do
  1044.    not support the Basic profile, and to allow Brokers to deal with
  1045.    Suppliers and Customers who are not CORBA-aware, as well as to allow
  1046.    delivery of items and data streams via the Broker, other open
  1047.    technologies are suggested as extensions to the Basic and Minimal
  1048.    profiles.  These technologies reflect the results of the technology
  1049.    evaluation carried out as part of the project GAIA.
  1050.  
  1051.    The extra protocols are grouped into Extension Modules.  Support of
  1052.    these Extension Modules is optional.  A Broker can choose an
  1053.    appropriate set of Extension Modules to conform to according to the
  1054.    functionality it wishes to achieve.  There is one Extension Module
  1055.    for each of the functional areas which are not covered by the Basic
  1056.    and Minimal Profiles, and also one Extension Module for each of the
  1057.    existing areas (Customer, Discovery, and Order) to allow the use of
  1058.    protocols other than GAIA abstract primitives.
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Blinov, et al.                                                 [Page 19]
  1067.  
  1068. RFC 2552                          GAIA                        April 1999
  1069.  
  1070.  
  1071.    The following Extension Modules are defined.
  1072.  
  1073.    - Discovery Extension Module
  1074.    - Order Extension Module
  1075.    - Discrete Delivery Extension Module
  1076.    - Stream Delivery Extension Module
  1077.    - Security Extension Module
  1078.    - Payment Extension Module
  1079.    - Alerting Extension Module
  1080.    - Customer Discovery Extension Module
  1081.  
  1082. 5.5.1.  Discovery Extension Module
  1083.  
  1084.    The Discovery Extension Module specifies the technologies to be used
  1085.    in searching for and locating products and services.
  1086.  
  1087.    This Extension Module requires the Broker to support the client part
  1088.    of the Z39.50 protocol, as defined in [5].  The following subset of
  1089.    the protocol is required:
  1090.  
  1091.    - Init, Search, and Present services
  1092.    - GRS-1 record syntax
  1093.  
  1094.    Z39.50 protocol PDUs should be carried using TCP/IP network
  1095.    protocols.
  1096.  
  1097.    +-------------------------------------------------+
  1098.    | Discovery Extension Module                      |
  1099.    +------------------------+------------------------+
  1100.    | Searching,             | Z39.50 (client)        |
  1101.    | Locating               |                        |
  1102.    +------------------------+------------------------+
  1103.  
  1104. 5.5.2.  Order Extension Module
  1105.  
  1106.    The Order Extension Module specifies the protocols to be used to
  1107.    order products and services from a Supplier.
  1108.  
  1109.    This Extension Module requires the Broker to support all mandatory
  1110.    services of the client part of the ISO ILL protocol [6].  Basic
  1111.    conformance criteria should be adhered to.  ISO ILL protocol PDUs
  1112.    should be carried using TCP/IP network protocols.
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Blinov, et al.                                                 [Page 20]
  1123.  
  1124. RFC 2552                          GAIA                        April 1999
  1125.  
  1126.  
  1127.    +-------------------------------------------------+
  1128.    | Order Extension Module                          |
  1129.    +------------------------+------------------------+
  1130.    | Order                  | ISO ILL (client)       |
  1131.    +------------------------+------------------------+
  1132.  
  1133. 5.5.3.  Discrete Delivery Extension Module
  1134.  
  1135.    The Discrete Delivery Extension Module specifies the protocols and
  1136.    standards to be used for the delivery of on-line products and
  1137.    services to the Customer.  There are two delivery scenarios
  1138.    considered
  1139.  
  1140.    - Direct Supplier to Customer delivery
  1141.      The delivery may be a single-step operation, with the Supplier
  1142.      supplying his product directly to the Customer without the
  1143.      involvement of any Broker in the delivery process.  The Broker may
  1144.      have acted to refer the Customer to the Supplier.  In this case,
  1145.      where the Broker is not involved in delivery, the Discrete Delivery
  1146.      Extension Module does not apply.
  1147.  
  1148.    - Delivery over a supply chain with one or more Brokers involved
  1149.      In the event of the Broker being the central link in a supply chain
  1150.      of the form of Supplier-Broker-Customer, the Broker will use the
  1151.      protocols specified in the Discrete Delivery Extension Module to
  1152.      receive the product from the Supplier, and to provide the product
  1153.      to the Customer.
  1154.  
  1155.    The Discrete Delivery Extension Module requires the Broker to provide
  1156.    both FTP client and FTP server functionality [7], to allow the Broker
  1157.    to receive and to transmit files using FTP.
  1158.  
  1159.    The Discrete Delivery Extension Module also requires the GAIA Broker
  1160.    to be able to accept and to generate e-mail messages.  The e-mail
  1161.    protocol specified is Internet e-mail, based on the SMTP protocol [8]
  1162.    and mail data formats specified in RFC 822 [9].  This protocol is
  1163.    sufficient for the creation, transmission, and management of textual
  1164.    e-mail messages.  However, for the transmission of data files of
  1165.    various types, extensions to the SMTP/RFC822 protocols are required.
  1166.    The mail extensions specified by the Discrete Delivery Extension
  1167.    Module are based on MIME (Multipurpose Internet Mail Extensions),
  1168.    defined in RFCs 2045-2049 [10].  Thus a GAIA Broker must be able to
  1169.    send and receive "simple" SMTP/RFC822 mail, and also be able to deal
  1170.    with RFC 2045-2049 MIME mail extensions.
  1171.  
  1172.    For electronic document delivery the Discrete Delivery Extension
  1173.    Module requires the support of GEDI version 3.0.
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Blinov, et al.                                                 [Page 21]
  1179.  
  1180. RFC 2552                          GAIA                        April 1999
  1181.  
  1182.  
  1183.    +--------------------------------------------------------+
  1184.    | Discrete Delivery Extension Module                     |
  1185.    +------------------------+-------------------------------+
  1186.    | FTP profile            | FTP (client+server)           |
  1187.    | Email profile          | Internet e-mail [SMTP,RFC822] |
  1188.    |                        |   (receiver+sender),          |
  1189.    |                        | MIME                          |
  1190.    | Document delivery      | GEDI version 3.0              |
  1191.    +------------------------+-------------------------------+
  1192.  
  1193. 5.5.4.  Stream Delivery Extension Module
  1194.  
  1195.    This Extension Module is intended to support real-time delivery of
  1196.    multimedia by the GAIA Broker.
  1197.  
  1198.    Several scenarios of stream delivery are considered.  A stream can be
  1199.    delivered
  1200.  
  1201.    - directly from a Supplier to a Customer
  1202.      The Broker does not take part in the stream delivery process; this
  1203.      scenario is out of scope of this standard.
  1204.  
  1205.    - from a Supplier to a Customer via a Broker
  1206.      The Broker can add value to the stream delivery process by
  1207.      implementing cache algorithms, mixing streams, branching one stream
  1208.      to several Customers, etc.
  1209.  
  1210.    - from a Broker to a Customer
  1211.      The Broker can keep a small amount of multimedia data (e.g. audio
  1212.      examples) in its own database and deliver it to a Customer upon
  1213.      request.
  1214.  
  1215.    The Stream Delivery Extension Module is recommended to be implemented
  1216.    by a Broker in order to provide the last two scenarios of real-time
  1217.    multimedia delivery.
  1218.  
  1219.    The Stream Delivery Extension Module requires the Broker to support
  1220.    the following technologies:
  1221.  
  1222.    - Compression
  1223.      MPEG-2 Audio Layer 3, specified in ISO/IEC 13818-3 [11].  Only
  1224.      support of constrained parameter streams (CSPS) is required.
  1225.  
  1226.    - Data transfer protocol
  1227.      RTP protocol over UDP/IP, defined in RFC 1889 [12] (both client and
  1228.      server parts).  It is recommended that the full behaviour of an RTP
  1229.      application service entity ("translator" or "mixer") is supported
  1230.      but it is not required.
  1231.  
  1232.  
  1233.  
  1234. Blinov, et al.                                                 [Page 22]
  1235.  
  1236. RFC 2552                          GAIA                        April 1999
  1237.  
  1238.  
  1239.    - Mapping
  1240.      RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13].
  1241.  
  1242.    - Session control protocol
  1243.      RTCP, specified in RFC 1889 [12].
  1244.  
  1245.    This profile provides delivery of high quality audio over networks
  1246.    with non-guaranteed quality of service such as the Internet.
  1247.  
  1248.    +----------------------------------------------------+
  1249.    | Stream Delivery Extension Module                   |
  1250.    +--------------------------+-------------------------+
  1251.    | Compression              | MPEG-2 Audio Layer 3    |
  1252.    | Data transfer            | RTP (client+server)     |
  1253.    | Mapping                  | RFC 2250                |
  1254.    | Session control protocol | RTCP                    |
  1255.    +--------------------------+-------------------------+
  1256.  
  1257. 5.5.5.  Security Extension Module
  1258.  
  1259.    The basic security services required for GAIA are
  1260.  
  1261.    - Authentication of users, remote servers (both as entity
  1262.      authentication and as bilateral peer-to-peer authentication),
  1263.      senders and receivers in network transactions, as well as the
  1264.      authentication of documents.  Authentication is required for three
  1265.      situations: authentication at the user workstation when starting
  1266.      the session, authentication in a local environment (client/server
  1267.      authentication) and authentication in a global, open network
  1268.      (Internet).
  1269.  
  1270.    - Confidentiality and integrity of all resources transferred over the
  1271.      network or handled locally at application servers and user
  1272.      workstations.
  1273.  
  1274.    - Control of access to services and resources.
  1275.  
  1276.    - Non-repudiation of transactions, participants, and sensitive
  1277.      documents.
  1278.  
  1279.    This module allows a Broker to secure communications with other
  1280.    participants.  It provides channel security, authentication, and
  1281.    certificate exchange.
  1282.  
  1283.    The Security Extension Module specifies the following protocols and
  1284.    algorithms:
  1285.  
  1286.    - Privacy, integrity, non-repudiation
  1287.  
  1288.  
  1289.  
  1290. Blinov, et al.                                                 [Page 23]
  1291.  
  1292. RFC 2552                          GAIA                        April 1999
  1293.  
  1294.  
  1295.      SSL v3.0 protocol, defined in [14].
  1296.      PKCS #7, defined in [15].
  1297.  
  1298.    - Remote, client/server authentication
  1299.      GSS v5, specified in RFC 1508 [16].
  1300.  
  1301.    - Certification services
  1302.      PKIX certification protocol, specified in [17].
  1303.  
  1304.    +-----------------------------------------------------------+
  1305.    | Security Extension Module                                 |
  1306.    +--------------------------------------+--------------------+
  1307.    | Privacy, integrity, non-repudiation  | SSL v 3.0, PKCS #7 |
  1308.    | Remote, client/server authentication | GSS v5             |
  1309.    | Certification services               | PKIX certification |
  1310.    |                                      |      protocol      |
  1311.    +--------------------------------------+--------------------+
  1312.  
  1313. 5.5.6.  Payment Extension Module
  1314.  
  1315.    This module allows a Broker to perform electronic payment operations
  1316.    with Customers, Suppliers, and other Brokers.  Such operations may take
  1317.    place at any stage during a GAIA transaction, during a Search, Locate,
  1318.    Order, or Deliver Action.
  1319.  
  1320.    The GAIA Standard does not specify the tariffing or charging model to
  1321.    be used by a Broker; this is considered to be an internal matter.
  1322.    However, when a bill has been agreed, payment must take place in a
  1323.    secure and mutually acceptable manner.  The payment procedure specified
  1324.    in the GAIA Standard makes use of the SET specification.
  1325.  
  1326.    The Payment Extension Module requires a Broker to support SET v1.0
  1327.    merchant's server and SET certification protocol, specified in [18].
  1328.  
  1329.    +----------------------------------------------------+
  1330.    | Payment Extension Module                           |
  1331.    +------------------------+---------------------------+
  1332.    | Payment                | SET v 1.0 :               |
  1333.    |                        | 1) CA server for banks    |
  1334.    |                        | 2) Cardholder wallet      |
  1335.    |                        | 3) Merchant Server        |
  1336.    |                        | 4) Payment Gateway server |
  1337.    +------------------------+---------------------------+
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Blinov, et al.                                                 [Page 24]
  1347.  
  1348. RFC 2552                          GAIA                        April 1999
  1349.  
  1350.  
  1351. 5.5.7.  Alerting Extension Module
  1352.  
  1353.    The Alerting Extension Module specifies the protocols to notify
  1354.    Customers about changes that can be interesting for them.
  1355.  
  1356.    This Extension Module requires the support of the following
  1357.    technologies:
  1358.  
  1359.    - Internet e-mail, based on SMTP protocol [8],
  1360.      and mail data formats specified in RFC 822 [9].
  1361.      The Broker should be able to generate and send e-mail messages.
  1362.    - SMS (Short Message Service), specified in [19].
  1363.  
  1364.    +-----------------------------------------------------+
  1365.    | Alerting Extension Module                           |
  1366.    +-----------+-----------------------------------------+
  1367.    | Alerting  | Internet e-mail [SMTP,RFC822] (sender), |
  1368.    |           | SMS                                     |
  1369.    +-----------+-----------------------------------------+
  1370.  
  1371. 5.5.8.  Customer Discovery Extension Module
  1372.  
  1373.    The Customer Discovery Extension Module allows Z39.50 clients to use
  1374.    the service of the GAIA Broker.
  1375.  
  1376.    This Extension Module requires the Broker to support the server part
  1377.    of the Z39.50 protocol, as defined in [5].  The following subset of
  1378.    the protocol is required:
  1379.  
  1380.    - Init, Search, and Present services
  1381.    - GRS-1 record syntax
  1382.  
  1383.    Z39.50 protocol PDUs should be carried using TCP/IP network
  1384.    protocols.
  1385.  
  1386.    +----------------------------------------------------+
  1387.    | Discovery Extension Module                         |
  1388.    +------------------------+---------------------------+
  1389.    | Searching,             | Z39.50 (server)           |
  1390.    | Locating               |                           |
  1391.    +------------------------+---------------------------+
  1392.  
  1393. 5.6.  Interface Modules
  1394.  
  1395.    For the purpose of conformance, all interfaces between FUMs and FUs,
  1396.    specified by the GAIA Standard, are grouped into GAIA Interface
  1397.    Modules.  These modules are recommended to be supported by a GAIA
  1398.    Broker, but they are not mandatory.  A Broker can choose a subset of
  1399.  
  1400.  
  1401.  
  1402. Blinov, et al.                                                 [Page 25]
  1403.  
  1404. RFC 2552                          GAIA                        April 1999
  1405.  
  1406.  
  1407.    Interface Modules that are more important in its area of operation,
  1408.    and implement interfaces defined in these modules.
  1409.  
  1410.    A full specification of the Functional Unit interfaces is presented
  1411.    in the GAIA Standard [1].
  1412.  
  1413.    The following table defines Interface Modules and specifies which
  1414.    interfaces have to be supported in each of them.
  1415.  
  1416.    +--------------------+------------------------------------+
  1417.    | Interface Module   | Interfaces that are required to be |
  1418.    |                    | supported in this module           |
  1419.    +--------------------+------------------------------------+
  1420.    | Search             | Search FU interface                |
  1421.    | Locate             | Locate FU interface                |
  1422.    | Order              | Order FU interface                 |
  1423.    | Discrete Delivery  | Discrete Delivery FU interface     |
  1424.    | Stream Delivery    | Stream Delivery FU interface       |
  1425.    | Customer           | Customer FU interface              |
  1426.    | Alerting           | Alerting FU interface              |
  1427.    | Directory Services | Directory Services FU interface    |
  1428.    | Authentication     | Authentication FU interface        |
  1429.    | Payment            | Payment FU interface               |
  1430.    +--------------------+------------------------------------+
  1431.  
  1432. 6.  Acknowledgement
  1433.  
  1434.    We wish to express our gratitude to all members of the GAIA
  1435.    Consortium for a very lively discussion and their valuable direct and
  1436.    indirect input in the design process of the GAIA Standard.
  1437.  
  1438. 7.  Security Considerations
  1439.  
  1440.    Security issues related to the electronic brokerage are discussed in
  1441.    Sections 2.1.4, 2.3 and 5.4.5.
  1442.  
  1443. 8.  References
  1444.  
  1445.    [1]  GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)",
  1446.         December 1998, see also <http://www.syspace.co.uk/GAIA/>.
  1447.  
  1448.    [2]  Object Management Group, "CORBA 2.0 Specification", July 1996,
  1449.         See <ftp://ftp.omg.org/pub/docs/formal/97-02-25.pdf>.
  1450.  
  1451.    [3]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
  1452.         Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
  1453.         2068, January 1997.
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Blinov, et al.                                                 [Page 26]
  1459.  
  1460. RFC 2552                          GAIA                        April 1999
  1461.  
  1462.  
  1463.    [4]  Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
  1464.         2.0", RFC 1866, November 1995.
  1465.  
  1466.    [5]  ANSI/NISO Z39.50-1995 or ISO 23950 "Information Retrieval:
  1467.         Application Service Definition and Protocol Specification".
  1468.  
  1469.    [6]  ISO 10161:1997 "Information and documentation -- Open Systems
  1470.         Interconnection -- Interlibrary Loan Application Protocol
  1471.         Specification".
  1472.  
  1473.    [7]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
  1474.         959, October 1985.
  1475.  
  1476.    [8]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  1477.         August 1982.
  1478.  
  1479.    [9]  Crocker, D., "Standard for the format of ARPA Internet text
  1480.         messages", STD 11, RFC 822, August 1982.
  1481.  
  1482.    [10] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
  1483.         Extensions (MIME) Part One: Format of Internet Message Bodies",
  1484.         RFC 2045, November 1996.
  1485.  
  1486.         Freed, N., and N. Borenstein, "Multipurpose Internet Mail
  1487.         Extensions (MIME) Part Two: Media Types", RFC 2046, November
  1488.         1996.
  1489.  
  1490.         Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
  1491.         Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
  1492.         November 1996.
  1493.  
  1494.         Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
  1495.         Mail Extensions (MIME) Part Four: Registration Procedures", RFC
  1496.         2048, November 1996.
  1497.  
  1498.         Freed, N., and N. Borenstein, "Multipurpose Internet Mail
  1499.         Extensions (MIME) Part Five: Conformance Criteria and Examples",
  1500.         RFC 2049, November 1996.
  1501.  
  1502.    [11] ISO/IEC IS 13818 "Information technology -- Coding of moving
  1503.         pictures and associated audio information"
  1504.  
  1505.         Part 1: Systems
  1506.         Part 2: Video
  1507.         Part 3: Audio
  1508.         Part 4: Conformance testing
  1509.         Part 5: Software simulation
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Blinov, et al.                                                 [Page 27]
  1515.  
  1516. RFC 2552                          GAIA                        April 1999
  1517.  
  1518.  
  1519.    [12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
  1520.         "RTP: A Transport Protocol for Real-Time Applications", RFC
  1521.         1889, January 1996.
  1522.  
  1523.    [13] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
  1524.         Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
  1525.  
  1526.    [14] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol -
  1527.         Version 3.0", Work in Progress, Transport Layer Security Working
  1528.         Group, November 1996, See
  1529.         <http://home.netscape.com/eng/ssl3/index.html>.
  1530.  
  1531.    [15] PKCS #7: Cryptographic Message Syntax Standard.  Version 1.5,
  1532.         November 1993.
  1533.  
  1534.    [16] Linn, J., "Generic Security Service Application Program
  1535.         Interface", RFC 1508, Geer Zolot Associate, September 1993.
  1536.  
  1537.    [17] Public-Key Infrastructure (X.509) IETF Working Group,
  1538.         <http://www.ietf.org/html.charters/pkix-charter.html>, July 98.
  1539.  
  1540.    [18] "SET Secure Electronic Transaction Specification", Version 1.0,
  1541.         MasterCard and Visa, May 97.
  1542.  
  1543.    [19] Digital Cellular Telecommunications System (Phase 2+): Technical
  1544.         Realization of the Short Message Service (SMS) Point-to-Point
  1545.         (PP) (GSM 3.40).  Version 5.2.0.  European Telecommunications
  1546.         Standards Institute.  May 1996.
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Blinov, et al.                                                 [Page 28]
  1571.  
  1572. RFC 2552                          GAIA                        April 1999
  1573.  
  1574.  
  1575. 9.  Authors' Addresses
  1576.  
  1577.    Mikhail Blinov
  1578.    Computer Science Department
  1579.    University College Dublin
  1580.    Belfield, Dublin 4, Ireland
  1581.  
  1582.    Phone: +353 1-706-2488
  1583.    Fax:   +353 1-269-7262
  1584.    EMail: mch@net-cs.ucd.ie
  1585.  
  1586.  
  1587.    Mikhail Bessonov
  1588.    Computer Science Department
  1589.    University College Dublin
  1590.    Belfield, Dublin 4, Ireland
  1591.  
  1592.    Phone: +353 1-706-2488
  1593.    Fax:   +353 1-269-7262
  1594.    EMail: mikeb@net-cs.ucd.ie
  1595.  
  1596.  
  1597.    Ciaran Clissmann
  1598.    Computer Science Department
  1599.    University College Dublin
  1600.    Belfield, Dublin 4, Ireland
  1601.  
  1602.    Phone: +353 1-706-2488
  1603.    Fax:   +353 1-269-7262
  1604.    EMail: ciaranc@net-cs.ucd.ie
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Blinov, et al.                                                 [Page 29]
  1627.  
  1628. RFC 2552                          GAIA                        April 1999
  1629.  
  1630.  
  1631. 10.  Full Copyright Statement
  1632.  
  1633.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  1634.  
  1635.    This document and translations of it may be copied and furnished to
  1636.    others, and derivative works that comment on or otherwise explain it
  1637.    or assist in its implementation may be prepared, copied, published
  1638.    and distributed, in whole or in part, without restriction of any
  1639.    kind, provided that the above copyright notice and this paragraph are
  1640.    included on all such copies and derivative works.  However, this
  1641.    document itself may not be modified in any way, such as by removing
  1642.    the copyright notice or references to the Internet Society or other
  1643.    Internet organizations, except as needed for the purpose of
  1644.    developing Internet standards in which case the procedures for
  1645.    copyrights defined in the Internet Standards process must be
  1646.    followed, or as required to translate it into languages other than
  1647.    English.
  1648.  
  1649.    The limited permissions granted above are perpetual and will not be
  1650.    revoked by the Internet Society or its successors or assigns.
  1651.  
  1652.    This document and the information contained herein is provided on an
  1653.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1654.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1655.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1656.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1657.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1658.  
  1659.  
  1660.  
  1661.  
  1662.  
  1663.  
  1664.  
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Blinov, et al.                                                 [Page 30]
  1683.  
  1684.