home *** CD-ROM | disk | FTP | other *** search
Text File | 1999-10-14 | 65.4 KB | 1,684 lines |
-
-
-
-
-
-
- Network Working Group M. Blinov
- Request for Comments: 2552 M. Bessonov
- Category: Informational C. Clissmann
- Teltec UCD-CS
- Ireland
- April 1999
-
- Architecture for Information Brokerage
- in the ACTS Project GAIA
-
- Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- Abstract
-
- This memo introduces a domain and supplier independent generic
- architecture for information brokerage, designed as part of the ACTS
- project GAIA (Generic Architecture for Information Availability).
-
- 1. Introduction
-
- Today a huge number of goods and services are offered on the
- electronic market by a large, and ever-increasing, number of
- suppliers. However, there is still no efficient way for a customer
- to find a product or information, he/she is interested in and a
- supplier that can provide that product. Customers and suppliers
- already can not deal with the quantity of available information by
- themselves. The high heterogeneity of existing protocols, formats,
- and underlying networks also limits development of the electronic
- market.
-
- This results in a demand for brokerage systems that can work as
- intermediary entities between customers and content suppliers.
- Brokerage systems assist a customer during the trading process and
- hide the heterogeneity and distribution of information from the
- customer. The design of domain and supplier independent generic
- architecture for such brokerage systems is an objective of the
- project GAIA (Generic Architecture for Information Availability).
- GAIA received part funding from the EU ACTS programme for Research
- and Technological Development. The GAIA brokerage system allows a
- customer to
-
-
-
- Blinov, et al. [Page 1]
-
- RFC 2552 GAIA April 1999
-
-
- - search for a particular "product" (information, content or
- services) that he/she is interested in
- - locate the product, i.e. find supplier(s) from whom the product is
- available
- - order the product from the supplier
- - receive delivery of the product by digital means
-
- All these actions are carried out by the broker in response to
- requests from the customer. Broker services are accessible to the
- customer through the unified user interface. The customer system
- does not have to support all the protocols involved in the trading
- process.
-
- Full specification of the GAIA Architecture is available in the GAIA
- Standard [1]. The GAIA Standard includes a description of the GAIA
- Reference Model, GAIA Functional Architecture, GAIA Standard
- Profiles, and specification of the GAIA interfaces.
-
- This memo does not aim to include the whole text of the GAIA
- Standard, but to present the basic ideas and concepts of this
- standard.
-
- The structure of this memo follows the structure of the GAIA
- Standard:
-
- 1. The GAIA Reference Model provides a common basis for the
- description and specification of brokerage systems, including the
- GAIA system.
-
- 2. The GAIA Functional Architecture defines functional elements of
- the GAIA Broker, their roles and relationships.
-
- 3. The GAIA Brokerage System Interfaces describes internal and
- external interfaces of the GAIA brokerage system.
-
- 4. The GAIA Standard Profiles specifies mandatory and optional
- profiles to which brokerage systems may conform.
-
- 2. The GAIA Reference Model
-
- The Generic Architecture for Information Availability (GAIA)
- Reference Model outlines the operations and actors involved in
- finding, ordering, and delivering physical and digital objects and
- services ("Products") in a global brokered distributed information
- environment. It provides an overall view of the GAIA environment,
- and illustrates the respective roles of and relationships between its
-
-
-
-
-
- Blinov, et al. [Page 2]
-
- RFC 2552 GAIA April 1999
-
-
- components. Further work on standards and frameworks for individual
- components of the GAIA environment uses the model and terminology
- provided by the Reference Model.
-
- The GAIA environment is a collection of actors and functions that are
- combined to support a procedure for information and services
- discovery, order, and delivery. The actors play roles in the
- procedure, including initiation and execution of the Actions which
- are combined to make up the overall transaction. The GAIA
- architecture provides a standardised and widely applicable framework
- for the provision and implementation of the brokered search and
- retrieve applications in a large-scale networked environment.
-
- 2.1. GAIA Roles
-
- The GAIA model considers three principal roles that can be played by
- the GAIA actors. These are the Customer, the Broker and the
- Supplier. These Roles are shown in Figure 1 below. It also
- considers a further class of active entities who play supporting
- roles in the Actions. This latter class is known as GAIA "Helpers"
- and includes, for example, authentication and payment. The actors
- are organisations and individuals in the supply chain. Every GAIA
- actor plays at least one role at any given time.
-
- 2.1.1. The Customer
-
- The aim of the Customer is to obtain some Products or information
- about some Products. The Customer role initiates the GAIA
- transaction by requesting one or more GAIA Actions, and receives the
- results of the transaction. The Customer may deal with actors
- playing either of the other two roles: the Broker or the Supplier.
- These actors may themselves play the role of the Customer while
- requesting further services from other Brokers.
-
- 2.1.2. The Broker
-
- The Broker provides brokerage services to the Customer and the
- Supplier. It responds to requests from the Customer to provide
- Products, or information about Products. The Products that the
- Broker supplies to the Customer may originate from one or more
- Suppliers and/or Brokers. The Broker's primary role is to act as a
- collector and collator of information from a number of different
- Suppliers, and to supply this information to the Customer, thus
- obviating the need for the Customer to deal with a variety of
- Suppliers. A Broker can also be considered to act on behalf of a
- Supplier, distributing information about the Products available. The
- actor playing the role of the Broker may play the role of a Supplier
-
-
-
-
- Blinov, et al. [Page 3]
-
- RFC 2552 GAIA April 1999
-
-
- to a Customer or other Broker at the same time. The Broker may play
- the role of a Customer while interacting with another Broker or with
- a Supplier.
-
- 2.1.3. The Supplier
-
- The Supplier is the source of the Product supplied to the Customer.
- The Supplier provides the Broker with information about the Product
- that it can supply. The Supplier may supply its Product directly to
- the Customer, or to the Broker for forwarding to the Customer. An
- actor playing the role of a Supplier may also play the role of a
- Broker. A Supplier may deal with a large number of Brokers and
- Customers over a number of GAIA transactions.
-
- 2.1.4. Helpers
-
- A Helper is an application layer entity playing a supporting role in
- a GAIA transaction. Helpers provide some service needed in the
- supply chain, but outside the core functionality of the Broker.
- Examples include a global directory service, payment service, or
- authentication service.
-
- The authentication Helper is concerned with facilitating the
- authentication of one actor to another.
-
- The payment Helper is concerned with supporting a mechanism for
- payment to one actor by another.
-
- In any given GAIA transaction, there will be one or more Customers
- (usually one), one or more Brokers, and one or more Suppliers. A
- description of the Product sought by the Customer is provided by the
- Customer to the Broker. The Broker may involve other Brokers in the
- search for the Product. When a Supplier of the Product is discovered
- by the Broker, this information is included in the response of the
- Broker to the Customer. During the course of the Action, it may be
- necessary to call upon the services of one or more Helpers.
-
- 2.2. GAIA Actions
-
- Each GAIA transaction is made up of one or more Actions. These
- Actions are requests by the Customer to the Broker or the Supplier to
- carry out some operation and to return a response. Four Actions are
- defined:
-
- - Search
- - Locate
- - Order
- - Deliver
-
-
-
- Blinov, et al. [Page 4]
-
- RFC 2552 GAIA April 1999
-
-
- These Actions are shown in Figure 1.
-
- +--------+ . . +--------+ . . +-----------+
- | |-- Search -->| |-- Search -->| |+
- | | : : | | : : | ||
- | |-- Locate -->| |-- Locate -->| ||
- |Customer| : : | Broker | : : |Supplier(s)||
- | |-- Order --->| |-- Order --->| ||
- | | : : | | : : | ||
- | |<- Deliver --| |<- Deliver --| ||
- +--------+ : : +--------+ : : +-----------+|
- : : : : +-----------+
- Helpers Helpers
- <Authentication> <Payment> <Security>
-
- Figure 1 GAIA Roles and Actions
-
- 2.2.1. Search
-
- The Search Action is carried out when the Customer asks the Broker to
- find some information on its behalf. To do this, the Customer
- provides the Broker with some description of the Product it requires.
- On the basis of this description, the Broker carries out a search on
- behalf of the Customer and returns the result. The result of a
- Search Action is a set of unique identifiers referencing the Products
- matching the description provided by the Customer.
-
- 2.2.2. Locate
-
- The Locate Action is carried out when the Customer asks the Broker to
- provide it with information regarding the location and source of some
- Product. To allow the Broker to do this, the Customer provides an
- unambiguous identification of the Product, which may be the result of
- a Search Action. The Broker returns information to the Customer
- about a source or sources for the Product. These data include the
- Terms of Availability information such as available methods of
- delivery, time of delivery, costs, etc. However, this information
- can not be considered final since some special terms and conditions
- may apply, e.g. discounts for some categories of Customers. The
- final version of the Terms of Availability is established during the
- negotiation phase of the Order Action.
-
- 2.2.3. Order
-
- The Order Action is carried out when the Customer asks the Broker to
- obtain a Product on its behalf, or asks the Supplier to sell the
- Product directly to the Customer. To enable an Order, the Customer
- provides the Broker/Supplier with Product source information, which
-
-
-
- Blinov, et al. [Page 5]
-
- RFC 2552 GAIA April 1999
-
-
- may be a result of a Locate Action. The Order Action consists of a
- negotiation phase and (possibly) a purchase phase. During the
- negotiation phase the Customer obtains the quotation that contains
- the final version of the Terms of Availability for the (batch of)
- Products he is considering purchasing. If the Customer finds these
- conditions satisfactory, he commits to the purchase. Alternatively,
- if the Broker or Supplier supports telepresence services for the
- human interaction with the Supplier or Broker representatives, these
- may be used during the negotiations.
-
- 2.2.4. Deliver
-
- The Deliver Action is carried out when the Broker provides the
- Customer with some requested Product. The Product may be
- information, some physical object, or metadata. The Deliver Action
- may be in response to an Order Action, a Search Action, or a Locate
- Action.
-
- While the Actions presented in this section may logically be taken to
- form an integrated sequence, this is not necessarily the case.
- Actions may take place independently, rather than as a part of a
- four-Action whole. For example, Order and Deliver Actions may occur
- on the basis of information obtained by the Customer using some other
- mechanism than GAIA Search and Locate Actions.
-
- 2.3. GAIA Helper Events
-
- During any of the GAIA Actions outlined above, it may be necessary to
- carry out some supporting activity. These activities are called GAIA
- Helper events. They include, for example, authentication and
- payment. The Helper entities are involved in the GAIA events to
- provide services, additional to the GAIA Actions, to the GAIA actors.
-
- Authentication
-
- In order to verify the identity of one GAIA actor to another, an
- authentication exchange may need to take place. This may occur
- during any of the GAIA Actions. The manner or method of
- authentication is outside the scope of this document.
-
- Payment
-
- It may be necessary for payment to take place during a GAIA
- transaction. In this situation, one GAIA actor pays one or more
- other GAIA actors. The manner or method of payment is outside the
- scope of this document.
-
-
-
-
-
- Blinov, et al. [Page 6]
-
- RFC 2552 GAIA April 1999
-
-
- Security
-
- As part of any GAIA Action, it may be necessary to carry out some
- security operations, such as encryption of data, verification of
- source and content integrity of Product, or digital signature of some
- data entity or entities. The particular security services and
- mechanisms which may be required, or the manner in which they may be
- provided, is outside the scope of this document.
-
- 3. The GAIA Functional Architecture
-
- 3.1. The Concept
-
- The GAIA Functional Architecture decomposes the overall functionality
- of the GAIA Broker into a number of components and describes the
- roles and relationships of these components, and the manner in which
- they interoperate.
-
- To work in a heterogeneous environment the GAIA Functional
- Architecture introduces three levels of abstract elements of the
- Broker: the Kernel, Functional Unit Managers (FUMs), and Functional
- Units (FUs) (see Figure 2).
-
- GAIA Broker:
- ------------
- [ Kernel ] Kernel
- / \ level
- / \
- [Functional Unit] [Functional Unit] Technology-independent
- [ Manager ] [ Manager ] action-dependent
- / \ / \ level
- / \ / \
- [Functional][Functional] [Functional][Functional] Technology
- [Unit ][Unit ] [Unit ][Unit ] dependent
- level
- Figure 2 Levels of the architecture
-
- Functional Units are the technology dependent parts of the
- architecture. They perform required transactions in terms of a
- particular protocol. All FUs are covered by a technology independent
- interface. FUs are grouped according to the trading action they
- participate in, e.g. search FUs or locate FUs. Each group of FUs is
- governed by the corresponding Functional Unit Manager.
-
- Functional Unit Managers contain technology independent functions for
- particular actions. To use a particular technology an FUM uses the
- services of attached FUs. There may be several FUs associated with
- an FUM, allowing the FUM to operate in different technology contexts.
-
-
-
- Blinov, et al. [Page 7]
-
- RFC 2552 GAIA April 1999
-
-
- There is one FUM in the system for every area of functionality, e.g.
- search, locate, and order. The Kernel is responsible for managing
- the activity of different FUMs (corresponding to different actions)
- and synchronising events between them.
-
- The GAIA Functional Architecture establishes relationships between
- the existing technologies (standards and protocols) that are combined
- in the GAIA Standard, in the context of a brokerage system. It is to
- be expected that new technologies will evolve which will be viable
- alternatives to those selected. The abstract and modular nature of
- the Functional Architecture allows the replacement of one technology
- with a new one without disruption to the rest of the brokerage
- system.
-
- 3.2. Functional Units
-
- The brokerage system provides a number of services to its users.
- These services are supported by the functions of the brokerage
- system. These include, for example,
-
- - searching
- - ordering
- - payment
-
- Each of these functions can be provided by a number of different
- candidate technologies. However, the operations that are required to
- be carried out remain the same. Regardless of the selected
- technologies, the functional requirements do not change. The
- required operations are described in terms of abstract primitives,
- which can be mapped to the protocol instructions of the technology
- selected to support the function. A mapping component, called a
- Functional Unit (FU), is defined for each candidate technology, and
- converts calls to abstract primitives into protocol instructions.
- The FU acts as an adaptor between its particular technology and the
- rest of the brokerage system.
-
- Functional Units are defined for each candidate technology that can
- be used to fulfil a particular functional need of the brokerage
- system. A Functional Unit accepts abstract primitive invocations,
- and maps them to calls to the particular technology to which it is
- dedicated. The results of these calls are translated into the
- corresponding abstract primitives and returned by the FU, as shown in
- Figure 3.
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 8]
-
- RFC 2552 GAIA April 1999
-
-
- * The rest of the Broker *
- ^
- | -abstract primitives
- v
- +------------+
- | Functional |
- | Unit |
- +------------+
- ^
- | -technology-specific commands
- v
- * Technology functions *
-
- Figure 3 GAIA Functional Unit
-
- 3.3. Functional Unit Managers
-
- As noted above, a number of different candidate technologies can be
- used to fulfil a particular functional requirement of the brokerage
- system. Depending on the details of the GAIA transaction (underlying
- network, Customer system capabilities, etc.), different technologies
- may be more useful during different transactions. As a result, each
- candidate technology has its own Functional Unit, which is invoked
- when that particular technology is required.
-
- A number of different Functional Units can exist which fulfil the
- same functional requirement of the brokerage system. To select the
- most appropriate FU (and technology), the brokerage system needs to
- know which is the most useful at any particular time; in general this
- is the technology supported by the target Supplier system. This is
- the responsibility of the Functional Unit Manager, or FUM. Each
- function of the brokerage system has a single FUM, which is invoked
- using abstract primitives by the Broker Kernel. This FUM selects the
- most appropriate of the candidate technologies, and calls the
- corresponding FU (see Figure 4).
-
- The interface between the FUM and the corresponding FUs is defined
- for every FUM in an open, platform independent, and programming
- language independent manner. These interfaces do not depend on any
- particular technology. It allows for configuring the set of
- technologies supported by the Broker, by attaching different subsets
- of FUs. If a new technology is to be supported by a Broker, a new FU
- implementing this technology can be created according to the
- specification of the interface, and attached to the corresponding
- FUM.
-
-
-
-
-
-
- Blinov, et al. [Page 9]
-
- RFC 2552 GAIA April 1999
-
-
- +--------------------------------------+
- | Functional Unit Manager |
- +--------------------------------------+
- ^ ^
- | -abstract primitives- |
- v v
- +------------+ +------------+
- | Functional | | Functional |
- | Unit | | Unit |
- +------------+ +------------+
- ^ ^
- | -technology-specific commands- |
- v v
- * Technology * * Technology *
- * functions * * functions *
-
- Figure 4 Functional Unit Manager
-
- 3.4. The Kernel
-
- The Kernel of the brokerage system acts as a bus for the transmission
- of abstract primitives between FUMs. Each FUM imports a set of
- abstract primitives representing those services which the FUM expects
- to receive from some other part of the system. The services that the
- FUM is prepared to provide to other elements of the brokerage system
- are presented in the form of exported abstract primitives. All these
- abstract primitives are imported from, and exported to, the Kernel
- (see Figure 5).
-
- The Kernel is also responsible for synchronisation of different
- actions within a transaction and for maintaining a common context
- between actions.
-
- +-------------------------------------+
- | Broker Kernel |
- +-------------------------------------+
- ^ ^ ^
- | -abstract- | -primitives- |
- v v v
- +-------+ +-------+ +-------+
- | FUM | | FUM | | FUM |
- +-------+ +-------+ +-------+
-
- Figure 5 Broker Kernel
-
-
-
-
-
-
-
- Blinov, et al. [Page 10]
-
- RFC 2552 GAIA April 1999
-
-
- 3.5. Description of FUMs
-
- The core activities of the brokerage system include:
-
- 1. searching for Products that fit a user description
- 2. sourcing Products the identification of which is known
- 3. allowing users to order Products
- 4. delivering information in item format
- 5. delivering information as a continuous media stream
- 6. providing a user interface to the brokerage services
- 7. alerting users as to the availability of information
- 8. interacting with external directory services
- 9. authentication of other actors
- 10. payment operations
-
- Each of these activities is carried out by the corresponding FUM as
- described below and shown in Figure 6.
-
- Search FUM
-
- The Search FUM accepts requests to carry out a search for Products
- that fit a particular user description. It returns lists of
- identifiers of Products that fit the description.
-
- Locate FUM
-
- The Locate FUM accepts Product identifiers and discovers where they
- may be obtained. It returns lists of Suppliers and locations for the
- Product.
-
- Order FUM
-
- The Order FUM manages negotiations between a Customer and a Supplier
- in order that agreement may be reached on the terms of availability
- of a particular Product or group of Products. Following the
- negotiation phase, the Order FUM accepts purchase commitments from
- the Customer and forwards them to the Supplier. It returns a
- notification of the status of the Order Action.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 11]
-
- RFC 2552 GAIA April 1999
-
-
- The GAIA Broker:
- ----------------
- (Customer)) (Alerting)) ( DS )) (Auth)) (Payment))
- ( FUs )) ( FUs )) ( FUs )) ( FUs)) ( FUs ))
- (e.g.HTTP)) (e.g. SMS)) (eg LDAP)) ( )) (e.g.SET))
- \/ \/ \/ \/ \/
- [Customer] [Alerting] [ DS ] [ Auth ] [Payment]
- [ FUM ] [ FUM ] [ FUM ] [ FUM ] [ FUM ]
- | | | | |
- +----------------------------------------------------------+
- | Broker Kernel |
- +----------------------------------------------------------+
- | | | | |
- [ Search ] [ Locate ] [ Order ] [ Stream ] [Discrete]
- [ FUM ] [ FUM ] [ FUM ] [Delivery] [Delivery]
- [ ] [ ] [ ] [ FUM ] [ FUM ]
- /\ /\ /\ /\ /\
- ( Search )) ( Locate )) ( Order )) ( SD )) ( DD ))
- ( FUs )) ( FUs )) ( FUs )) ( FUs )) ( FUs ))
- (eg Z39.50)) (eg Z39.50)) (eg ISO ILL)) (eg RTP)) (eg FTP))
-
- Figure 6 GAIA Functional Architecture
-
-
- Discrete Delivery FUM
-
- The Discrete Delivery FUM manages the delivery of discrete items to
- the Customer.
-
- Stream Delivery FUM
-
- The Stream Delivery FUM manages the delivery of real-time multimedia
- data streams to the Customer.
-
- Customer FUM
-
- The Customer FUM provides an interface to support the Customer's
- systems interaction with the brokerage system.
-
- Alerting FUM
-
- The Alerting FUM notifies Customers about changes that may interest
- them.
-
- Directory Services FUM
-
- The Directory Services FUM provides an interface between an external
- directory service and the brokerage system.
-
-
-
- Blinov, et al. [Page 12]
-
- RFC 2552 GAIA April 1999
-
-
- Authentication FUM
-
- The Authentication FUM provides a mechanism that allows a user to
- prove his identity to the brokerage system.
-
- Payment FUM
-
- The Payment FUM provides a mechanism for payment from one actor to
- another.
-
- 4. GAIA Brokerage System Interfaces
-
- This Chapter describes the internal and external interfaces of the
- GAIA brokerage system.
-
- 4.1. Internal Interfaces
-
- The definition of communication between functional components within
- the GAIA Broker is based on the OMG CORBA model [2]. Interfaces
- between components are defined in the IDL language specified by OMG.
- Interface calls are passed between components by the Object Request
- Broker (ORB).
-
- The advantage of this approach is that the specifications of the
- interfaces are platform and programming language independent. These
- interfaces can be implemented using different programming languages
- on different platforms. All necessary conversions during interface
- invocations are transparently performed by an ORB. The CORBA model
- also allows installing different functional components of the GAIA
- Broker on different computers connected by a network. Interface
- calls will be transferred over the network by an ORB transparently
- for the application.
-
- The specification of the interfaces between the Kernel and FUMs and
- between each FUM and corresponding FUs is presented in the GAIA
- Standard [1].
-
- 4.2. External protocols
-
- The GAIA Broker can use existing protocols to communicate with other
- actors. For example, it can use HTTP for interactions with
- Customers, Z39.50 for search, etc. As described in the GAIA
- Functional Architecture, support for particular technologies is
- provided by FUs. A set of supported protocols can be extended by
- attaching the corresponding new FUs to a Broker. The GAIA Broker can
- support several protocols for each action. The FUMs will select the
- most appropriate protocol for a transaction. The more protocols
- supported by the Broker, the better service it can provide to
-
-
-
- Blinov, et al. [Page 13]
-
- RFC 2552 GAIA April 1999
-
-
- Customers and Suppliers.
-
- The GAIA Standard does not limit the set of protocols supported by
- the Broker. However, for the purpose of interoperability, it
- specifies several GAIA profiles. These profiles define a common
- subset of protocols (and a common range of protocol parameters) that
- Brokers are encouraged to support in order to make communication
- between GAIA Brokers, and with GAIA-aware Suppliers and Customers,
- possible.
-
- Existing protocols are not the only way to contact the GAIA Broker.
- The GAIA interfaces have been designed as a generalisation of
- existing interfaces and protocols, so they provide more functionality
- than any particular protocol. To give access to the full
- functionality of the GAIA Broker, the GAIA Standard allows users
- (Customers and other Brokers) to directly use the CORBA-defined
- Customer interface of the GAIA Broker (interface between the Customer
- FUM and FUs) as shown in Figure 7. In this case, the Customer system
- gets access to the Customer interface of the Broker using the service
- of an underlying ORB, and can request operations by calling the
- corresponding methods of the interface. The Customer interface of
- the GAIA Broker is specified in the GAIA Standard [1].
-
- Where Customer and Supplier systems are not CORBA-aware, they can
- communicate with a GAIA Broker using existing protocols. If,
- however, they can use the service of an ORB, they are encouraged to
- communicate with a Broker by connecting to its Customer interface.
- This method allows for avoiding convergence between a particular
- protocol and the GAIA interface. The former method makes
- interactions with all existing types of Customers and Suppliers
- possible using existing and widespread protocols. The later method
- has been designed to achieve maximum functionality by using native
- GAIA methods for communication with Customers and Suppliers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 14]
-
- RFC 2552 GAIA April 1999
-
-
- +----------------+
- |Broker |
- | |
- | -------- |
- +-----------+ | [ Kernel ] |
- | Broker | | -------- |
- | or | | [Customer] |
- | Customer | | [ FUM ] |
- | | | ========== <-GAIA Customer
- | * | | * * | \interface
- | { O R B *}* * * * * * *{* O R B * } |
- +-----------+ iiop | * | +----------+
- | (Customer) | | Customer |
- | ( FU ) | | |
- +------------I---+ +----I-----+
- \ HTTP /
- - - - - - -
-
- Figure 7 External protocols and the GAIA Customer interface
-
- 5. GAIA Standard Profiles
-
- The GAIA Standard defines a number of profiles, which a Broker may
- support in order to achieve interoperability with other GAIA actors
- (Customers, Suppliers and other Brokers). The complexity of the
- profile chosen by a Broker depends on the level and type of service
- which the Broker wishes to deliver in a GAIA-conformant manner. The
- higher the level of service that a Broker provides to a Customer, and
- the greater the length of the supply chain which the Broker wishes to
- support, the more advanced the profile and/or the greater the number
- of extension modules the Broker must support.
-
- 5.1. Supply Chains
-
- The GAIA profile definition approach is based on the possible types
- of supply chain that a brokerage system can be a part of.
-
- The operations of a brokerage system can be broken into three
- categories:
-
- - interactions with the Customer
- - interactions with other Brokers
- - interactions with Suppliers
-
- The first and last of these occur at the two ends of a supply chain,
- while interbroker operations take place at other points in the chain.
- The supply chain may take a number of different forms:
-
-
-
-
- Blinov, et al. [Page 15]
-
- RFC 2552 GAIA April 1999
-
-
- - a minimal chain, where the Customer and the Broker are the ends of
- the chain and there are no intervening links. In this case, the
- Broker plays the role of Supplier to the Customer.
-
- - a three-piece chain, where the Broker deals with the Customer and
- the Supplier but not with any other Broker.
-
- - a longer chain, with one or more interbroker operations.
-
- Minimal Supply Chain:
- +--------+ +-------------+
- |Customer| <=====> | Broker |
- +--------+ |(as Supplier)|
- +-------------+
- 3-piece Supply Chain:
- +--------+ +--------+ +--------+
- |Customer| <===> | Broker | <===> |Supplier|
- +--------+ +--------+ +--------+
- Longer Supply Chain:
- +--------+ +--------+ +--------+ +--------+
- |Customer| <===> | Broker |<=>| Broker | <===> |Supplier|
- +--------+ +--------+ +--------+ +--------+
-
- Figure 8 Supply Chains
-
- 5.1.1. Minimal Supply Chains
-
- As discussed in the GAIA Reference Model, a GAIA transaction is
- composed of a number of actions, such as search, order, and delivery.
- Each transaction is initiated by the Customer who makes a request to
- the Broker. In the event that the Broker is able to fulfil the
- request, the transaction involves no other actors.
-
- In this simple case, the GAIA transaction involves the Customer and
- the Broker. The only protocol which needs to be standardised is that
- between the Customer and the Broker. This is specified in the GAIA
- Standard Minimal profile below.
-
- 5.1.2. Longer Supply Chains
-
- In the event that the Broker is not able to fulfil a request, the
- action may be propagated on to other Brokers, with the original
- Broker playing the Customer role. Each of these Brokers may in turn
- propagate the request if they cannot fulfil it.
-
- Eventually, if the action is successful, a Supplier will be found who
- can fulfil the request. The supply chain is thus made up a single
- Customer, one or more Suppliers, and one or more Brokers.
-
-
-
- Blinov, et al. [Page 16]
-
- RFC 2552 GAIA April 1999
-
-
- In order to propagate an action from one Broker to another, a
- standardised communication protocol must be defined for broker-broker
- interaction. This is specified in the Basic profile, below. This
- profile is based on CORBA.
-
- Supplier and Brokers, however, are not obliged to support the Basic
- profile of the GAIA Standard. They may instead use another, more
- traditional, protocol such as Z39.50 for discovery, or ISO ILL for
- ordering. The Extension Modules to the GAIA Standard specify the
- profiles to be used for various brokerage functions.
-
- 5.2. Introduction to the GAIA Standard Profiles and Modules
-
- The profiles specified are
-
- - The Minimal profile, which is the very least to which a GAIA Broker
- must conform
- - The Basic Profile, which allows inter-broker communication
- - A number of Extension Modules, which allow the Broker to provide
- various services, and to interoperate with Suppliers, Brokers and
- Customers using protocols specified in the modules
- - A set of Interface Modules, that defines which particular
- Functional Unit CORBA interfaces are supported by the Broker
-
- Each Broker must conform at least to the Minimal profile to provide a
- web-based user interface. In addition, to take part in inter-broker
- communications, the Basic profile is recommended. For interaction
- with non-CORBA-aware entities, and for the use of advanced services,
- there are other modules of the standard to which the Broker may
- conform. These are denoted "Extension Modules", and they
- characterise the protocols and standards in a particular area of
- functionality. A Broker can choose an appropriate set of Extension
- Modules to conform to according to the functionality it wishes to
- achieve.
-
- The GAIA Standard specifies all interfaces between FUM and FUs for
- the GAIA Broker. However, it would be too much to require every
- Broker to implement all of them. The GAIA Standard decomposes all
- interfaces into a number of Interface Modules. A Broker can choose a
- subset of Interface Modules that are more important in its area of
- operation, and implement interfaces defined in these modules. These
- interfaces are important only inside the broker system and do not
- play any role in communication with other GAIA actors. However, a
- declaration of supported interfaces is important for the
- administrator to find the areas in which the functionality of the
- Broker can be extended by attaching GAIA-conformant FUs.
-
-
-
-
-
- Blinov, et al. [Page 17]
-
- RFC 2552 GAIA April 1999
-
-
- 5.3. Minimal Profile
-
- The minimum functionality that a Broker must support will allow it to
- provide services to the Customer as a part of a minimal chain. In
- this case, what is required of the Broker is simply a user interface
- for the Customer. Any further operations take place within the
- Broker, and so do not come within the scope of the standard.
-
- The Minimal profile requires the Broker to implement a user interface
- based on the HTTP 1.1 protocol, defined in RFC 2068 [3], and HTML
- 2.0, defined in RFC 1866 [4]. It means that a Customer should be
- able to access the basic functionality of the GAIA Broker by using a
- HTTP 1.1 and HTML 2.0 conformant web-browser.
-
- It should be possible for Customers to locate a GAIA Broker. Thus a
- GAIA Broker should be registered in a Directory Service using a
- schema specified in the GAIA Standard [1].
-
- +-------------------------------------------------+
- | Minimal Profile |
- +------------------------+------------------------+
- | Customer | HTTP 1.1 (server), |
- | | HTML 2.0 |
- +------------------------+------------------------+
-
- 5.4. Basic Profile
-
- While the minimal functionality is sufficient to allow a Broker to
- function, an important aspect of any GAIA Broker functionality is
- dealing with other Brokers. The goal of the Basic profile is to
- achieve federation between Brokers. Every GAIA Broker can use the
- service of other GAIA Brokers in order to fulfil a request of a
- Customer. That Broker in turn can use the service of the third GAIA
- Broker. So every request can be chained by several Brokers. This
- extends the abilities of every GAIA action (Search, Locate, Order,
- etc.). Chained transactions are particularly important in the
- discovery phase of a transaction, where a Broker unable to fulfil a
- particular information requirement passes on the search to another
- Broker.
-
- The Basic profile requires the Broker to implement the GAIA Customer
- interface defined in terms of CORBA. This interface is described in
- more detail in Section 4.2 above. The Basic profile also requires
- the Broker to implement interface requestor procedures, i.e. to be
- able to connect to the Customer interfaces of other Brokers. The ORB
- used by the Broker should be conformant to the CORBA 2.0
- specification [2] and use IIOP protocol for inter-ORB communications
- [2].
-
-
-
- Blinov, et al. [Page 18]
-
- RFC 2552 GAIA April 1999
-
-
- A full specification of the GAIA Customer interface is presented in
- the GAIA Standard [1].
-
- A GAIA Broker should be able to find other Brokers and Suppliers. It
- should also allow other participants to find it. Thus a GAIA Broker
- should support a directory service. The Basic profile includes a
- directory access protocol for this purpose. The actual choice of
- protocol is not standardised, because the choice does not influence
- the success of the Broker's inter-operation with other Brokers. The
- directory schema, which should be used, is specified in the GAIA
- Standard.
-
- The Basic profile suggested for a Broker to allow it to interoperate
- with other GAIA Brokers is as follows.
-
- +----------------------------------------------------------------+
- | Basic Profile |
- +------------------------+---------------------------------------+
- | Customer | GAIA Customer interface/IIOP (server) |
- | Search and Locate | GAIA Customer interface/IIOP (client) |
- | (Discovery) | |
- | Order | GAIA Customer interface/IIOP (client) |
- | Directory | Some directory access protocol, |
- | | such as LDAP |
- +------------------------+---------------------------------------+
-
- 5.5. Extension Modules
-
- In order to allow Brokers to interoperate with other Brokers that do
- not support the Basic profile, and to allow Brokers to deal with
- Suppliers and Customers who are not CORBA-aware, as well as to allow
- delivery of items and data streams via the Broker, other open
- technologies are suggested as extensions to the Basic and Minimal
- profiles. These technologies reflect the results of the technology
- evaluation carried out as part of the project GAIA.
-
- The extra protocols are grouped into Extension Modules. Support of
- these Extension Modules is optional. A Broker can choose an
- appropriate set of Extension Modules to conform to according to the
- functionality it wishes to achieve. There is one Extension Module
- for each of the functional areas which are not covered by the Basic
- and Minimal Profiles, and also one Extension Module for each of the
- existing areas (Customer, Discovery, and Order) to allow the use of
- protocols other than GAIA abstract primitives.
-
-
-
-
-
-
-
- Blinov, et al. [Page 19]
-
- RFC 2552 GAIA April 1999
-
-
- The following Extension Modules are defined.
-
- - Discovery Extension Module
- - Order Extension Module
- - Discrete Delivery Extension Module
- - Stream Delivery Extension Module
- - Security Extension Module
- - Payment Extension Module
- - Alerting Extension Module
- - Customer Discovery Extension Module
-
- 5.5.1. Discovery Extension Module
-
- The Discovery Extension Module specifies the technologies to be used
- in searching for and locating products and services.
-
- This Extension Module requires the Broker to support the client part
- of the Z39.50 protocol, as defined in [5]. The following subset of
- the protocol is required:
-
- - Init, Search, and Present services
- - GRS-1 record syntax
-
- Z39.50 protocol PDUs should be carried using TCP/IP network
- protocols.
-
- +-------------------------------------------------+
- | Discovery Extension Module |
- +------------------------+------------------------+
- | Searching, | Z39.50 (client) |
- | Locating | |
- +------------------------+------------------------+
-
- 5.5.2. Order Extension Module
-
- The Order Extension Module specifies the protocols to be used to
- order products and services from a Supplier.
-
- This Extension Module requires the Broker to support all mandatory
- services of the client part of the ISO ILL protocol [6]. Basic
- conformance criteria should be adhered to. ISO ILL protocol PDUs
- should be carried using TCP/IP network protocols.
-
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 20]
-
- RFC 2552 GAIA April 1999
-
-
- +-------------------------------------------------+
- | Order Extension Module |
- +------------------------+------------------------+
- | Order | ISO ILL (client) |
- +------------------------+------------------------+
-
- 5.5.3. Discrete Delivery Extension Module
-
- The Discrete Delivery Extension Module specifies the protocols and
- standards to be used for the delivery of on-line products and
- services to the Customer. There are two delivery scenarios
- considered
-
- - Direct Supplier to Customer delivery
- The delivery may be a single-step operation, with the Supplier
- supplying his product directly to the Customer without the
- involvement of any Broker in the delivery process. The Broker may
- have acted to refer the Customer to the Supplier. In this case,
- where the Broker is not involved in delivery, the Discrete Delivery
- Extension Module does not apply.
-
- - Delivery over a supply chain with one or more Brokers involved
- In the event of the Broker being the central link in a supply chain
- of the form of Supplier-Broker-Customer, the Broker will use the
- protocols specified in the Discrete Delivery Extension Module to
- receive the product from the Supplier, and to provide the product
- to the Customer.
-
- The Discrete Delivery Extension Module requires the Broker to provide
- both FTP client and FTP server functionality [7], to allow the Broker
- to receive and to transmit files using FTP.
-
- The Discrete Delivery Extension Module also requires the GAIA Broker
- to be able to accept and to generate e-mail messages. The e-mail
- protocol specified is Internet e-mail, based on the SMTP protocol [8]
- and mail data formats specified in RFC 822 [9]. This protocol is
- sufficient for the creation, transmission, and management of textual
- e-mail messages. However, for the transmission of data files of
- various types, extensions to the SMTP/RFC822 protocols are required.
- The mail extensions specified by the Discrete Delivery Extension
- Module are based on MIME (Multipurpose Internet Mail Extensions),
- defined in RFCs 2045-2049 [10]. Thus a GAIA Broker must be able to
- send and receive "simple" SMTP/RFC822 mail, and also be able to deal
- with RFC 2045-2049 MIME mail extensions.
-
- For electronic document delivery the Discrete Delivery Extension
- Module requires the support of GEDI version 3.0.
-
-
-
-
- Blinov, et al. [Page 21]
-
- RFC 2552 GAIA April 1999
-
-
- +--------------------------------------------------------+
- | Discrete Delivery Extension Module |
- +------------------------+-------------------------------+
- | FTP profile | FTP (client+server) |
- | Email profile | Internet e-mail [SMTP,RFC822] |
- | | (receiver+sender), |
- | | MIME |
- | Document delivery | GEDI version 3.0 |
- +------------------------+-------------------------------+
-
- 5.5.4. Stream Delivery Extension Module
-
- This Extension Module is intended to support real-time delivery of
- multimedia by the GAIA Broker.
-
- Several scenarios of stream delivery are considered. A stream can be
- delivered
-
- - directly from a Supplier to a Customer
- The Broker does not take part in the stream delivery process; this
- scenario is out of scope of this standard.
-
- - from a Supplier to a Customer via a Broker
- The Broker can add value to the stream delivery process by
- implementing cache algorithms, mixing streams, branching one stream
- to several Customers, etc.
-
- - from a Broker to a Customer
- The Broker can keep a small amount of multimedia data (e.g. audio
- examples) in its own database and deliver it to a Customer upon
- request.
-
- The Stream Delivery Extension Module is recommended to be implemented
- by a Broker in order to provide the last two scenarios of real-time
- multimedia delivery.
-
- The Stream Delivery Extension Module requires the Broker to support
- the following technologies:
-
- - Compression
- MPEG-2 Audio Layer 3, specified in ISO/IEC 13818-3 [11]. Only
- support of constrained parameter streams (CSPS) is required.
-
- - Data transfer protocol
- RTP protocol over UDP/IP, defined in RFC 1889 [12] (both client and
- server parts). It is recommended that the full behaviour of an RTP
- application service entity ("translator" or "mixer") is supported
- but it is not required.
-
-
-
- Blinov, et al. [Page 22]
-
- RFC 2552 GAIA April 1999
-
-
- - Mapping
- RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13].
-
- - Session control protocol
- RTCP, specified in RFC 1889 [12].
-
- This profile provides delivery of high quality audio over networks
- with non-guaranteed quality of service such as the Internet.
-
- +----------------------------------------------------+
- | Stream Delivery Extension Module |
- +--------------------------+-------------------------+
- | Compression | MPEG-2 Audio Layer 3 |
- | Data transfer | RTP (client+server) |
- | Mapping | RFC 2250 |
- | Session control protocol | RTCP |
- +--------------------------+-------------------------+
-
- 5.5.5. Security Extension Module
-
- The basic security services required for GAIA are
-
- - Authentication of users, remote servers (both as entity
- authentication and as bilateral peer-to-peer authentication),
- senders and receivers in network transactions, as well as the
- authentication of documents. Authentication is required for three
- situations: authentication at the user workstation when starting
- the session, authentication in a local environment (client/server
- authentication) and authentication in a global, open network
- (Internet).
-
- - Confidentiality and integrity of all resources transferred over the
- network or handled locally at application servers and user
- workstations.
-
- - Control of access to services and resources.
-
- - Non-repudiation of transactions, participants, and sensitive
- documents.
-
- This module allows a Broker to secure communications with other
- participants. It provides channel security, authentication, and
- certificate exchange.
-
- The Security Extension Module specifies the following protocols and
- algorithms:
-
- - Privacy, integrity, non-repudiation
-
-
-
- Blinov, et al. [Page 23]
-
- RFC 2552 GAIA April 1999
-
-
- SSL v3.0 protocol, defined in [14].
- PKCS #7, defined in [15].
-
- - Remote, client/server authentication
- GSS v5, specified in RFC 1508 [16].
-
- - Certification services
- PKIX certification protocol, specified in [17].
-
- +-----------------------------------------------------------+
- | Security Extension Module |
- +--------------------------------------+--------------------+
- | Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 |
- | Remote, client/server authentication | GSS v5 |
- | Certification services | PKIX certification |
- | | protocol |
- +--------------------------------------+--------------------+
-
- 5.5.6. Payment Extension Module
-
- This module allows a Broker to perform electronic payment operations
- with Customers, Suppliers, and other Brokers. Such operations may take
- place at any stage during a GAIA transaction, during a Search, Locate,
- Order, or Deliver Action.
-
- The GAIA Standard does not specify the tariffing or charging model to
- be used by a Broker; this is considered to be an internal matter.
- However, when a bill has been agreed, payment must take place in a
- secure and mutually acceptable manner. The payment procedure specified
- in the GAIA Standard makes use of the SET specification.
-
- The Payment Extension Module requires a Broker to support SET v1.0
- merchant's server and SET certification protocol, specified in [18].
-
- +----------------------------------------------------+
- | Payment Extension Module |
- +------------------------+---------------------------+
- | Payment | SET v 1.0 : |
- | | 1) CA server for banks |
- | | 2) Cardholder wallet |
- | | 3) Merchant Server |
- | | 4) Payment Gateway server |
- +------------------------+---------------------------+
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 24]
-
- RFC 2552 GAIA April 1999
-
-
- 5.5.7. Alerting Extension Module
-
- The Alerting Extension Module specifies the protocols to notify
- Customers about changes that can be interesting for them.
-
- This Extension Module requires the support of the following
- technologies:
-
- - Internet e-mail, based on SMTP protocol [8],
- and mail data formats specified in RFC 822 [9].
- The Broker should be able to generate and send e-mail messages.
- - SMS (Short Message Service), specified in [19].
-
- +-----------------------------------------------------+
- | Alerting Extension Module |
- +-----------+-----------------------------------------+
- | Alerting | Internet e-mail [SMTP,RFC822] (sender), |
- | | SMS |
- +-----------+-----------------------------------------+
-
- 5.5.8. Customer Discovery Extension Module
-
- The Customer Discovery Extension Module allows Z39.50 clients to use
- the service of the GAIA Broker.
-
- This Extension Module requires the Broker to support the server part
- of the Z39.50 protocol, as defined in [5]. The following subset of
- the protocol is required:
-
- - Init, Search, and Present services
- - GRS-1 record syntax
-
- Z39.50 protocol PDUs should be carried using TCP/IP network
- protocols.
-
- +----------------------------------------------------+
- | Discovery Extension Module |
- +------------------------+---------------------------+
- | Searching, | Z39.50 (server) |
- | Locating | |
- +------------------------+---------------------------+
-
- 5.6. Interface Modules
-
- For the purpose of conformance, all interfaces between FUMs and FUs,
- specified by the GAIA Standard, are grouped into GAIA Interface
- Modules. These modules are recommended to be supported by a GAIA
- Broker, but they are not mandatory. A Broker can choose a subset of
-
-
-
- Blinov, et al. [Page 25]
-
- RFC 2552 GAIA April 1999
-
-
- Interface Modules that are more important in its area of operation,
- and implement interfaces defined in these modules.
-
- A full specification of the Functional Unit interfaces is presented
- in the GAIA Standard [1].
-
- The following table defines Interface Modules and specifies which
- interfaces have to be supported in each of them.
-
- +--------------------+------------------------------------+
- | Interface Module | Interfaces that are required to be |
- | | supported in this module |
- +--------------------+------------------------------------+
- | Search | Search FU interface |
- | Locate | Locate FU interface |
- | Order | Order FU interface |
- | Discrete Delivery | Discrete Delivery FU interface |
- | Stream Delivery | Stream Delivery FU interface |
- | Customer | Customer FU interface |
- | Alerting | Alerting FU interface |
- | Directory Services | Directory Services FU interface |
- | Authentication | Authentication FU interface |
- | Payment | Payment FU interface |
- +--------------------+------------------------------------+
-
- 6. Acknowledgement
-
- We wish to express our gratitude to all members of the GAIA
- Consortium for a very lively discussion and their valuable direct and
- indirect input in the design process of the GAIA Standard.
-
- 7. Security Considerations
-
- Security issues related to the electronic brokerage are discussed in
- Sections 2.1.4, 2.3 and 5.4.5.
-
- 8. References
-
- [1] GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)",
- December 1998, see also <http://www.syspace.co.uk/GAIA/>.
-
- [2] Object Management Group, "CORBA 2.0 Specification", July 1996,
- See <ftp://ftp.omg.org/pub/docs/formal/97-02-25.pdf>.
-
- [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
- Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
- 2068, January 1997.
-
-
-
-
- Blinov, et al. [Page 26]
-
- RFC 2552 GAIA April 1999
-
-
- [4] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
- 2.0", RFC 1866, November 1995.
-
- [5] ANSI/NISO Z39.50-1995 or ISO 23950 "Information Retrieval:
- Application Service Definition and Protocol Specification".
-
- [6] ISO 10161:1997 "Information and documentation -- Open Systems
- Interconnection -- Interlibrary Loan Application Protocol
- Specification".
-
- [7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
- 959, October 1985.
-
- [8] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
- August 1982.
-
- [9] Crocker, D., "Standard for the format of ARPA Internet text
- messages", STD 11, RFC 822, August 1982.
-
- [10] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC 2045, November 1996.
-
- Freed, N., and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046, November
- 1996.
-
- Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
- Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
- November 1996.
-
- Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
- Mail Extensions (MIME) Part Four: Registration Procedures", RFC
- 2048, November 1996.
-
- Freed, N., and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Five: Conformance Criteria and Examples",
- RFC 2049, November 1996.
-
- [11] ISO/IEC IS 13818 "Information technology -- Coding of moving
- pictures and associated audio information"
-
- Part 1: Systems
- Part 2: Video
- Part 3: Audio
- Part 4: Conformance testing
- Part 5: Software simulation
-
-
-
-
- Blinov, et al. [Page 27]
-
- RFC 2552 GAIA April 1999
-
-
- [12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
- "RTP: A Transport Protocol for Real-Time Applications", RFC
- 1889, January 1996.
-
- [13] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
- Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
-
- [14] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol -
- Version 3.0", Work in Progress, Transport Layer Security Working
- Group, November 1996, See
- <http://home.netscape.com/eng/ssl3/index.html>.
-
- [15] PKCS #7: Cryptographic Message Syntax Standard. Version 1.5,
- November 1993.
-
- [16] Linn, J., "Generic Security Service Application Program
- Interface", RFC 1508, Geer Zolot Associate, September 1993.
-
- [17] Public-Key Infrastructure (X.509) IETF Working Group,
- <http://www.ietf.org/html.charters/pkix-charter.html>, July 98.
-
- [18] "SET Secure Electronic Transaction Specification", Version 1.0,
- MasterCard and Visa, May 97.
-
- [19] Digital Cellular Telecommunications System (Phase 2+): Technical
- Realization of the Short Message Service (SMS) Point-to-Point
- (PP) (GSM 3.40). Version 5.2.0. European Telecommunications
- Standards Institute. May 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 28]
-
- RFC 2552 GAIA April 1999
-
-
- 9. Authors' Addresses
-
- Mikhail Blinov
- Computer Science Department
- University College Dublin
- Belfield, Dublin 4, Ireland
-
- Phone: +353 1-706-2488
- Fax: +353 1-269-7262
- EMail: mch@net-cs.ucd.ie
-
-
- Mikhail Bessonov
- Computer Science Department
- University College Dublin
- Belfield, Dublin 4, Ireland
-
- Phone: +353 1-706-2488
- Fax: +353 1-269-7262
- EMail: mikeb@net-cs.ucd.ie
-
-
- Ciaran Clissmann
- Computer Science Department
- University College Dublin
- Belfield, Dublin 4, Ireland
-
- Phone: +353 1-706-2488
- Fax: +353 1-269-7262
- EMail: ciaranc@net-cs.ucd.ie
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 29]
-
- RFC 2552 GAIA April 1999
-
-
- 10. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Blinov, et al. [Page 30]
-
-