Network Working Group M. Blinov
Request for Comments: 2552 M. Bessonov
Category: Informational C. Clissmann
Teltec UCD-CS
Ireland
April 1999
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
ACTS项目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.
版权所有（C）互联网协会（1999年）。版权所有。
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).
本备忘录介绍了一种独立于域和供应商的信息经纪通用体系结构，该体系结构是ACTS项目GAIA（信息可用性通用体系结构）的一部分。
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
这导致了对经纪系统的需求，该系统可以作为客户和内容供应商之间的中介实体。经纪系统在交易过程中帮助客户，并对客户隐藏信息的异质性和分布。为此类经纪系统设计独立于领域和供应商的通用架构是GAIA项目（信息可用性通用架构）的目标。GAIA获得了欧盟ACTS研究和技术开发计划的部分资助。盖亚经纪系统允许客户
- 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.
GAIA体系结构的完整规范见GAIA标准[1]。GAIA标准包括对GAIA参考模型、GAIA功能架构、GAIA标准配置文件和GAIA接口规范的描述。
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.
本备忘录的目的不是包括GAIA标准的全部内容，而是介绍本标准的基本思想和概念。
The structure of this memo follows the structure of the GAIA Standard:
本备忘录的结构遵循GAIA标准的结构：
1. The GAIA Reference Model provides a common basis for the description and specification of brokerage systems, including the GAIA system.
1. GAIA参考模型为经纪系统（包括GAIA系统）的描述和规范提供了通用基础。
2. The GAIA Functional Architecture defines functional elements of the GAIA Broker, their roles and relationships.
2. GAIA功能架构定义了GAIA代理的功能元素、它们的角色和关系。
3. The GAIA Brokerage System Interfaces describes internal and external interfaces of the GAIA brokerage system.
3. GAIA经纪系统接口描述了GAIA经纪系统的内部和外部接口。
4. The GAIA Standard Profiles specifies mandatory and optional profiles to which brokerage systems may conform.
4. GAIA标准配置文件规定了经纪系统可能遵守的强制性和可选配置文件。
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
通用信息可用性体系结构（GAIA）参考模型概述了在全球代理分布式信息环境中查找、订购和交付物理和数字对象及服务（“产品”）所涉及的操作和参与者。它提供了GAIA环境的总体视图，并说明了其各自的角色和关系
components. Further work on standards and frameworks for individual components of the GAIA environment uses the model and terminology provided by the Reference Model.
组件。关于GAIA环境各个组件的标准和框架的进一步工作使用了参考模型提供的模型和术语。
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.
GAIA环境是参与者和功能的集合，这些参与者和功能组合在一起，以支持信息和服务发现、订购和交付的过程。参与者在过程中扮演角色，包括动作的启动和执行，这些动作组合起来构成整个事务。GAIA体系结构为在大规模网络环境中提供和实施代理搜索和检索应用程序提供了一个标准化和广泛适用的框架。
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.
盖亚模型考虑了盖亚参与者可以扮演的三个主要角色。他们是客户、经纪人和供应商。这些角色如下图1所示。它还考虑了在行动中起辅助作用的另一类活动实体。后一类被称为GAIA“助手”，包括身份验证和支付。参与者是供应链中的组织和个人。每个盖亚演员在任何给定时间至少扮演一个角色。
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.
客户的目标是获取某些产品或有关某些产品的信息。客户角色通过请求一个或多个GAIA操作来启动GAIA事务，并接收事务的结果。客户可以与扮演其他两个角色之一的参与者打交道：经纪人或供应商。这些参与者自己可能扮演客户的角色，同时要求其他经纪人提供进一步服务。
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
经纪人向客户和供应商提供经纪服务。它响应客户提供产品或产品信息的请求。经纪人向客户提供的产品可能来自一个或多个供应商和/或经纪人。经纪人的主要作用是充当多个不同供应商信息的收集者和整理者，并将这些信息提供给客户，从而避免客户与各种供应商打交道。经纪人也可以被视为代表供应商，分发有关可用产品的信息。扮演经纪人角色的参与者可以扮演供应商的角色
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.
同时向客户或其他经纪人发送。经纪人在与其他经纪人或供应商互动时可能扮演客户的角色。
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.
供应商是向客户提供产品的来源。供应商向经纪人提供其可以提供的产品信息。供应商可直接向客户供应其产品，或向中间商提供产品，以便转发给客户。扮演供应商角色的参与者也可以扮演经纪人的角色。一个供应商可以在一系列GAIA交易中与大量经纪人和客户打交道。
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.
助手是在GAIA事务中起支持作用的应用层实体。助手提供供应链中所需的一些服务，但不在代理的核心功能范围内。示例包括全局目录服务、支付服务或身份验证服务。
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.
在任何给定的GAIA交易中，将有一个或多个客户（通常为一个）、一个或多个经纪人和一个或多个供应商。客户向经纪人提供客户寻求的产品说明。经纪人可能会让其他经纪人参与产品搜索。当经纪人发现产品供应商时，该信息将包含在经纪人对客户的回复中。在行动过程中，可能需要求助于一名或多名助手。
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:
每个GAIA事务由一个或多个操作组成。这些行动是客户要求经纪人或供应商执行某些操作并返回响应的请求。定义了四项行动：
- Search - Locate - Order - Deliver
- 搜索-定位-订单-交付
These Actions are shown in Figure 1.
这些操作如图1所示。
+--------+ . . +--------+ . . +-----------+
| |-- Search -->| |-- Search -->| |+
| | : : | | : : | ||
| |-- Locate -->| |-- Locate -->| ||
|Customer| : : | Broker | : : |Supplier(s)||
| |-- Order --->| |-- Order --->| ||
| | : : | | : : | ||
| |<- Deliver --| |<- Deliver --| ||
+--------+ : : +--------+ : : +-----------+|
: : : : +-----------+
Helpers Helpers
<Authentication> <Payment> <Security>
+--------+ . . +--------+ . . +-----------+
| |-- Search -->| |-- Search -->| |+
| | : : | | : : | ||
| |-- Locate -->| |-- Locate -->| ||
|Customer| : : | Broker | : : |Supplier(s)||
| |-- Order --->| |-- Order --->| ||
| | : : | | : : | ||
| |<- Deliver --| |<- Deliver --| ||
+--------+ : : +--------+ : : +-----------+|
: : : : +-----------+
Helpers Helpers
<Authentication> <Payment> <Security>
Figure 1 GAIA Roles and Actions
图1:GAIA的角色和行动
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.
当客户要求经纪人代表其查找某些信息时，就会执行搜索操作。为此，客户向代理提供其所需产品的一些描述。基于此描述，代理代表客户执行搜索并返回结果。搜索操作的结果是一组唯一标识符，引用与客户提供的描述匹配的产品。
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.
定位操作是在客户要求代理向其提供有关某些产品的位置和来源的信息时执行的。为了允许代理这样做，客户提供产品的明确标识，这可能是搜索操作的结果。经纪人向客户返回有关产品来源的信息。这些数据包括可用性信息的条款，如可用的交付方法、交付时间、成本等。但是，由于某些特殊条款和条件可能适用，因此这些信息不能被视为最终信息，例如某些类别客户的折扣。在订单行动的协商阶段确定可用性条款的最终版本。
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
当客户要求经纪人代表其获取产品，或要求供应商直接向客户销售产品时，执行订单操作。为了启用订单，客户向经纪人/供应商提供产品源信息，这些信息
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.
可能是定位操作的结果。订单操作包括谈判阶段和（可能）采购阶段。在谈判阶段，客户获得报价单，其中包含其考虑购买的（批次）产品的最终可用性条款。如果客户发现这些条件令人满意，他承诺购买。或者，如果经纪人或供应商支持与供应商或经纪人代表进行人机交互的远程呈现服务，则可在谈判期间使用这些服务。
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.
虽然在逻辑上可以采取本节中介绍的行动，以形成一个完整的序列，但情况并非如此。行动可以独立进行，而不是作为四个行动整体的一部分。例如，订购和交付操作可能基于客户使用GAIA搜索和定位操作以外的其他机制获得的信息。
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.
在上述任何GAIA行动期间，可能需要开展一些支持活动。这些活动称为GAIA助手事件。例如，它们包括身份验证和支付。帮助者实体参与盖亚事件，为盖亚参与者提供盖亚行动之外的服务。
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.
为了向另一个GAIA参与者验证一个GAIA参与者的身份，可能需要进行身份验证交换。这可能发生在任何盖亚行动期间。认证方式或方法不在本文件范围内。
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.
可能需要在GAIA交易期间进行支付。在这种情况下，一个盖亚演员支付一个或多个其他盖亚演员。付款方式或方法不在本文件范围内。
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.
作为任何GAIA行动的一部分，可能需要执行一些安全操作，如数据加密、产品源和内容完整性验证，或某些数据实体的数字签名。可能需要的特定安全服务和机制，或提供这些服务和机制的方式，不在本文件的范围内。
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.
GAIA功能架构将GAIA代理的整体功能分解为多个组件，并描述这些组件的角色和关系，以及它们的互操作方式。
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功能架构引入了代理的三个抽象元素级别：内核、功能单元管理器（FUM）和功能单元（FUs）（见图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
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.
功能单元是体系结构中与技术相关的部分。它们根据特定协议执行所需的事务。所有FU均由独立于技术的接口覆盖。FU根据其参与的交易行为进行分组，例如搜索FU或定位FU。每组FU由相应的职能部门经理管理。
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.
功能单元管理器包含特定操作的独立于技术的功能。为了使用特定技术，FUM使用连接的FU的服务。可能有多个FU与FUM相关，允许FUM在不同的技术环境中运行。
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.
系统中的每个功能区域都有一个FUM，例如搜索、定位和订购。内核负责管理不同fum的活动（对应于不同的操作）并在它们之间同步事件。
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.
GAIA功能体系结构在经纪系统的上下文中，建立了GAIA标准中组合的现有技术（标准和协议）之间的关系。预计新技术将不断发展，成为选定技术的可行替代品。功能架构的抽象和模块化特性允许在不中断经纪系统其余部分的情况下用新技术替换一种技术。
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.
这些功能中的每一个都可以由许多不同的候选技术提供。但是，需要执行的操作保持不变。无论选择何种技术，功能需求都不会改变。所需的操作以抽象原语的形式描述，抽象原语可以映射到所选技术的协议指令，以支持该功能。为每种候选技术定义一个称为功能单元（FU）的映射组件，并将对抽象原语的调用转换为协议指令。FU充当其特定技术与经纪系统其他部分之间的适配器。
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.
为每个候选技术定义了功能单元，这些候选技术可用于满足经纪系统的特定功能需求。功能单元接受抽象原语调用，并将它们映射到它专用的特定技术的调用。这些调用的结果被转换为相应的抽象原语，并由FU返回，如图3所示。
* The rest of the Broker * ^ | -abstract primitives v +------------+ | Functional | | Unit | +------------+ ^ | -technology-specific commands v * Technology functions *
* 代理的其余部分*^ |-抽象原语v+----------------+|函数| |单元|+-----------+^ |-特定于技术的命令v*技术函数*
Figure 3 GAIA Functional Unit
图3:GAIA功能单元
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.
如上所述，许多不同的候选技术可用于满足经纪系统的特定功能需求。根据GAIA交易的细节（基础网络、客户系统功能等），不同的技术在不同的交易中可能更有用。因此，每种候选技术都有自己的功能单元，在需要特定技术时调用该功能单元。
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).
可以存在多个不同的功能单元，它们满足经纪系统的相同功能要求。为了选择最合适的FU（和技术），经纪系统需要知道在任何特定时间哪个最有用；一般来说，这是目标供应商系统支持的技术。这是职能部门经理或FUM的责任。经纪系统的每个函数都有一个FUM，由经纪内核使用抽象原语调用。该FUM选择最合适的候选技术，并调用相应的FU（见图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.
FUM和相应FUs之间的接口是以开放、平台独立和编程语言独立的方式为每个FUM定义的。这些接口不依赖于任何特定的技术。它允许通过附加不同的FU子集来配置代理支持的技术集。如果代理支持新技术，则可以根据接口规范创建实现该技术的新FU，并将其附加到相应的FUM。
+--------------------------------------+
| Functional Unit Manager |
+--------------------------------------+
^ ^
| -abstract primitives- |
v v
+------------+ +------------+
| Functional | | Functional |
| Unit | | Unit |
+------------+ +------------+
^ ^
| -technology-specific commands- |
v v
* Technology * * Technology *
* functions * * functions *
+--------------------------------------+
| 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
图4功能单元管理器
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).
经纪系统的内核充当FUM之间传输抽象原语的总线。每个FUM导入一组抽象原语，表示FUM希望从系统的其他部分接收的服务。FUM准备向经纪系统的其他元素提供的服务以导出的抽象原语的形式呈现。所有这些抽象原语都从内核导入，并导出到内核（参见图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 |
+-------+ +-------+ +-------+
+-------------------------------------+
| Broker Kernel |
+-------------------------------------+
^ ^ ^
| -abstract- | -primitives- |
v v v
+-------+ +-------+ +-------+
| FUM | | FUM | | FUM |
+-------+ +-------+ +-------+
Figure 5 Broker Kernel
图5代理内核
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
1. 搜索符合用户说明的产品2。采购标识已知的产品3。允许用户订购产品4。以项目格式5提供信息。以连续媒体流的形式传递信息6。向经纪服务7提供用户界面。提醒用户信息的可用性8。与外部目录服务交互9。其他行为者的认证10。支付业务
Each of these activities is carried out by the corresponding FUM as described below and shown in Figure 6.
这些活动中的每一项都由相应的FUM执行，如下所述，如图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.
搜索FUM接受搜索符合特定用户描述的产品的请求。它返回符合描述的产品标识符列表。
Locate FUM
定位FUM
The Locate FUM accepts Product identifiers and discovers where they may be obtained. It returns lists of Suppliers and locations for the Product.
Locate FUM接受产品标识，并发现可从何处获得这些标识。它返回产品的供应商和位置列表。
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.
订单FUM管理客户和供应商之间的谈判，以便就特定产品或产品组的可用性条款达成协议。在谈判阶段之后，订单FUM接受客户的采购承诺，并将其转发给供应商。它返回订单操作状态的通知。
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))
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
图6 GAIA功能架构
Discrete Delivery FUM
离散交货FUM
The Discrete Delivery FUM manages the delivery of discrete items to the Customer.
离散交付FUM管理向客户交付离散项目。
Stream Delivery FUM
气流输送烟
The Stream Delivery FUM manages the delivery of real-time multimedia data streams to the Customer.
流交付FUM管理向客户交付实时多媒体数据流。
Customer FUM
顾客烟
The Customer FUM provides an interface to support the Customer's systems interaction with the brokerage system.
客户FUM提供了一个接口，以支持客户系统与经纪系统的交互。
Alerting FUM
报警烟
The Alerting FUM notifies Customers about changes that may interest them.
警报FUM通知客户可能感兴趣的更改。
Directory Services FUM
目录服务
The Directory Services FUM provides an interface between an external directory service and the brokerage system.
目录服务FUM提供外部目录服务和经纪系统之间的接口。
Authentication FUM
认证烟
The Authentication FUM provides a mechanism that allows a user to prove his identity to the brokerage system.
身份验证FUM提供了一种机制，允许用户向经纪系统证明其身份。
Payment FUM
付款方式
The Payment FUM provides a mechanism for payment from one actor to another.
支付FUM提供了一种从一个参与者到另一个参与者的支付机制。
This Chapter describes the internal and external interfaces of the GAIA brokerage system.
本章描述了GAIA经纪系统的内部和外部接口。
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).
GAIA代理中功能组件之间通信的定义基于OMG CORBA模型[2]。组件之间的接口用OMG指定的IDL语言定义。接口调用由对象请求代理（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.
这种方法的优点是接口规范与平台和编程语言无关。这些接口可以在不同的平台上使用不同的编程语言实现。接口调用期间所有必要的转换都由ORB透明地执行。CORBA模型还允许在通过网络连接的不同计算机上安装GAIA代理的不同功能组件。接口调用将由ORB通过网络透明地传输给应用程序。
The specification of the interfaces between the Kernel and FUMs and between each FUM and corresponding FUs is presented in the GAIA Standard [1].
内核和FUM之间以及每个FUM和相应FUs之间的接口规范见GAIA标准[1]。
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
GAIA代理可以使用现有协议与其他参与者通信。例如，它可以使用HTTP与客户进行交互，使用Z39.50进行搜索等。如GAIA功能架构中所述，FUs提供对特定技术的支持。通过将相应的新FU附加到代理，可以扩展一组受支持的协议。GAIA代理可以为每个操作支持多个协议。FUMs将为交易选择最合适的协议。代理支持的协议越多，它可以为客户提供的服务就越好
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.
GAIA标准不限制代理支持的协议集。但是，为了实现互操作性，它指定了几个GAIA概要文件。这些概要文件定义了鼓励经纪人支持的协议通用子集（以及协议参数的通用范围），以便使GAIA经纪人之间以及与了解GAIA的供应商和客户之间的通信成为可能。
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].
现有协议不是联系GAIA代理的唯一方式。GAIA接口被设计为现有接口和协议的概括，因此它们提供了比任何特定协议更多的功能。为了访问GAIA代理的全部功能，GAIA标准允许用户（客户和其他代理）直接使用GAIA代理的CORBA定义的客户接口（客户FUM和FUs之间的接口），如图7所示。在这种情况下，客户系统使用底层ORB的服务访问代理的客户接口，并可以通过调用接口的相应方法请求操作。GAIA经纪人的客户界面在GAIA标准[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.
如果客户和供应商系统不了解CORBA，它们可以使用现有协议与GAIA代理通信。但是，如果他们可以使用ORB的服务，则鼓励他们通过连接到代理的客户界面与代理进行通信。该方法允许避免特定协议和GAIA接口之间的收敛。前一种方法使使用现有和广泛的协议与所有现有类型的客户和供应商进行交互成为可能。后一种方法旨在通过使用本地GAIA方法与客户和供应商进行沟通来实现最大功能。
+----------------+
|Broker |
| |
| -------- |
+-----------+ | [ Kernel ] |
| Broker | | -------- |
| or | | [Customer] |
| Customer | | [ FUM ] |
| | | ========== <-GAIA Customer
| * | | * * | \interface
| { O R B *}* * * * * * *{* O R B * } |
+-----------+ iiop | * | +----------+
| (Customer) | | Customer |
| ( FU ) | | |
+------------I---+ +----I-----+
\ HTTP /
- - - - - -
+----------------+
|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
图7外部协议和GAIA客户界面
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.
GAIA标准定义了许多配置文件，经纪人可以支持这些配置文件，以实现与其他GAIA参与者（客户、供应商和其他经纪人）的互操作性。代理选择的概要文件的复杂性取决于代理希望以符合GAIA的方式提供的服务的级别和类型。代理向客户提供的服务级别越高，并且代理希望支持的供应链长度越长，概要文件越高级，和/或代理必须支持的扩展模块数量越多。
The GAIA profile definition approach is based on the possible types of supply chain that a brokerage system can be a part of.
GAIA配置文件定义方法基于经纪系统可能参与的供应链类型。
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:
第一个和最后一个发生在供应链的两端，而中间商业务发生在供应链的其他点。供应链可采取多种不同形式：
- 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|
+--------+ +--------+ +--------+ +--------+
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
图8供应链
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.
正如GAIA参考模型中所讨论的，GAIA事务由许多操作组成，例如搜索、订购和交付。每笔交易都是由向经纪人提出请求的客户发起的。在经纪人能够满足请求的情况下，交易不涉及其他参与者。
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.
在这个简单的案例中，GAIA交易涉及客户和经纪人。唯一需要标准化的协议是客户和经纪人之间的协议。这在下面的GAIA标准最低配置文件中有规定。
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.
最终，如果行动成功，将找到能够满足要求的供应商。因此，供应链由单个客户、一个或多个供应商和一个或多个经纪人组成。
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.
为了将动作从一个代理传播到另一个代理，必须为代理交互定义一个标准化的通信协议。这在下面的基本配置文件中指定。此概要文件基于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.
然而，供应商和经纪人没有义务支持GAIA标准的基本概况。他们可以使用另一种更传统的协议，如Z39.50进行发现，或使用ISO-ILL进行订购。GAIA标准的扩展模块指定了用于各种经纪功能的配置文件。
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
- 最低配置文件，即GAIA经纪人必须遵守的最低配置文件-允许经纪人间通信的基本配置文件-许多扩展模块，允许经纪人提供各种服务，并与供应商进行互操作，使用模块中指定的协议的代理和客户-一组接口模块，定义代理支持哪些特定功能单元CORBA接口
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.
每个代理必须至少符合最低配置文件，以提供基于web的用户界面。此外，要参与经纪人间的沟通，建议使用基本配置文件。对于与非CORBA感知实体的交互，以及对于高级服务的使用，代理可以遵守标准的其他模块。这些模块被称为“扩展模块”，它们描述了特定功能领域中的协议和标准。代理可以根据希望实现的功能选择一组适当的扩展模块。
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.
GAIA标准为GAIA代理指定FUM和FUs之间的所有接口。然而，要求每一个代理都实现所有这些都太过分了。GAIA标准将所有接口分解为多个接口模块。代理可以选择在其操作区域中更重要的接口模块子集，并实现这些模块中定义的接口。这些接口仅在代理系统内部重要，在与其他GAIA参与者的通信中不起任何作用。但是，对于管理员来说，声明支持的接口对于找到可以通过附加符合GAIA的FUs来扩展代理功能的区域非常重要。
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.
最低配置文件要求代理基于RFC 2068[3]中定义的HTTP 1.1协议和RFC 1866[4]中定义的HTML 2.0实现用户界面。这意味着客户应该能够通过使用符合HTTP 1.1和HTML2.0的web浏览器访问GAIA Broker的基本功能。
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].
客户应该可以找到GAIA经纪人。因此，应该使用GAIA标准[1]中指定的模式在目录服务中注册GAIA代理。
+-------------------------------------------------+
| Minimal Profile |
+------------------------+------------------------+
| Customer | HTTP 1.1 (server), |
| | HTML 2.0 |
+------------------------+------------------------+
+-------------------------------------------------+
| Minimal Profile |
+------------------------+------------------------+
| Customer | HTTP 1.1 (server), |
| | HTML 2.0 |
+------------------------+------------------------+
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.
虽然最小的功能足以允许代理运行，但任何GAIA代理功能的一个重要方面是与其他代理打交道。基本概要文件的目标是实现代理之间的联合。每个GAIA经纪人都可以使用其他GAIA经纪人的服务来满足客户的请求。该代理反过来可以使用第三个GAIA代理的服务。因此，每个请求都可以由多个代理链接。这扩展了每个盖亚行动（搜索、定位、命令等）的能力。链式交易在交易的发现阶段尤其重要，在该阶段，无法满足特定信息要求的经纪人将搜索传递给另一经纪人。
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].
基本概要文件要求代理实现根据CORBA定义的GAIA客户接口。上述第4.2节对该接口进行了更详细的描述。基本配置文件还要求代理实现接口请求程序，即能够连接到其他代理的客户接口。代理使用的ORB应符合CORBA 2.0规范[2]，并使用IIOP协议进行ORB间通信[2]。
A full specification of the GAIA Customer interface is presented in the GAIA Standard [1].
GAIA标准[1]中介绍了GAIA客户界面的完整规范。
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.
盖亚经纪人应该能够找到其他经纪人和供应商。它还应该允许其他参与者找到它。因此，GAIA代理应该支持目录服务。基本配置文件包括用于此目的的目录访问协议。协议的实际选择并不是标准化的，因为选择不会影响经纪人与其他经纪人的成功互动。应该使用的目录模式在GAIA标准中指定。
The Basic profile suggested for a Broker to allow it to interoperate with other GAIA Brokers is as follows.
建议经纪人与其他GAIA经纪人进行互操作的基本配置文件如下所示。
+----------------------------------------------------------------+
| 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 |
+------------------------+---------------------------------------+
+----------------------------------------------------------------+
| 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 |
+------------------------+---------------------------------------+
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.
为了允许代理与不支持基本配置文件的其他代理进行互操作，并允许代理与不了解CORBA的供应商和客户打交道，以及允许通过代理交付项目和数据流，建议将其他开放技术作为基本和最小配置文件的扩展。这些技术反映了作为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.
额外的协议被分组到扩展模块中。支持这些扩展模块是可选的。代理可以根据希望实现的功能选择一组适当的扩展模块。基本和最低配置文件未涵盖的每个功能领域都有一个扩展模块，并且每个现有领域（客户、发现和订单）都有一个扩展模块，以允许使用GAIA抽象原语以外的协议。
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
- 发现扩展模块-订单扩展模块-离散交付扩展模块-流式交付扩展模块-安全扩展模块-支付扩展模块-警报扩展模块-客户发现扩展模块
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:
此扩展模块要求代理支持Z39.50协议的客户端部分，如[5]中所定义。需要协议的以下子集：
- Init, Search, and Present services - GRS-1 record syntax
- 初始化、搜索和呈现服务-GRS-1记录语法
Z39.50 protocol PDUs should be carried using TCP/IP network protocols.
Z39.50协议PDU应使用TCP/IP网络协议进行传输。
+-------------------------------------------------+
| Discovery Extension Module |
+------------------------+------------------------+
| Searching, | Z39.50 (client) |
| Locating | |
+------------------------+------------------------+
+-------------------------------------------------+
| Discovery Extension Module |
+------------------------+------------------------+
| Searching, | Z39.50 (client) |
| Locating | |
+------------------------+------------------------+
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.
此扩展模块要求代理支持ISO ILL协议客户端部分的所有强制服务[6]。应遵守基本一致性标准。ISO ILL协议PDU应使用TCP/IP网络协议进行传输。
+-------------------------------------------------+
| Order Extension Module |
+------------------------+------------------------+
| Order | ISO ILL (client) |
+------------------------+------------------------+
+-------------------------------------------------+
| Order Extension Module |
+------------------------+------------------------+
| Order | ISO ILL (client) |
+------------------------+------------------------+
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.
离散交付扩展模块要求代理提供FTP客户端和FTP服务器功能[7]，以允许代理使用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.
离散交付扩展模块还要求GAIA代理能够接受和生成电子邮件。指定的电子邮件协议是基于SMTP协议[8]和RFC 822[9]中指定的邮件数据格式的Internet电子邮件。此协议足以创建、传输和管理文本电子邮件。但是，对于各种类型的数据文件的传输，需要对SMTP/RFC822协议进行扩展。离散传递扩展模块指定的邮件扩展基于RFCs 2045-2049[10]中定义的MIME（多用途互联网邮件扩展）。因此，GAIA代理必须能够发送和接收“简单”SMTP/RFC822邮件，并且还能够处理RFC 2045-2049 MIME邮件扩展。
For electronic document delivery the Discrete Delivery Extension Module requires the support of GEDI version 3.0.
对于电子文档交付，离散交付扩展模块需要GEDI版本3.0的支持。
+--------------------------------------------------------+
| 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 |
+------------------------+-------------------------------+
+--------------------------------------------------------+
| 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 |
+------------------------+-------------------------------+
This Extension Module is intended to support real-time delivery of multimedia by the GAIA Broker.
此扩展模块旨在支持GAIA代理实时交付多媒体。
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.
- ISO/IEC 13818-3[11]中规定的压缩MPEG-2音频层3。只需要支持约束参数流（CSP）。
- 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.
- 数据传输协议UDP/IP上的RTP协议，在RFC 1889[12]中定义（客户端和服务器部分）。建议支持RTP应用程序服务实体（“translator”或“mixer”）的完整行为，但不是必需的。
- Mapping RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13].
- 映射RFC 2250[13]中定义的MPEG音频（MPA）的RTP有效负载格式。
- Session control protocol RTCP, specified in RFC 1889 [12].
- RFC 1889[12]中规定的会话控制协议RTCP。
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 |
+--------------------------+-------------------------+
+----------------------------------------------------+
| Stream Delivery Extension Module |
+--------------------------+-------------------------+
| Compression | MPEG-2 Audio Layer 3 |
| Data transfer | RTP (client+server) |
| Mapping | RFC 2250 |
| Session control protocol | RTCP |
+--------------------------+-------------------------+
The basic security services required for GAIA are
GAIA所需的基本安全服务包括：
- 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).
- 在网络交易中对用户、远程服务器（作为实体身份验证和双边对等身份验证）、发送方和接收方进行身份验证，以及对文档进行身份验证。在三种情况下需要身份验证：启动会话时在用户工作站进行身份验证、在本地环境中进行身份验证（客户端/服务器身份验证）以及在全局开放网络（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
- 隐私、完整性、不可否认性
SSL v3.0 protocol, defined in [14]. PKCS #7, defined in [15].
SSL v3.0协议，定义见[14]。PKCS#7，定义见[15]。
- Remote, client/server authentication GSS v5, specified in RFC 1508 [16].
- RFC 1508[16]中规定的远程、客户端/服务器身份验证GSS v5。
- Certification services PKIX certification protocol, specified in [17].
- [17]中规定的认证服务PKIX认证协议。
+-----------------------------------------------------------+
| Security Extension Module |
+--------------------------------------+--------------------+
| Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 |
| Remote, client/server authentication | GSS v5 |
| Certification services | PKIX certification |
| | protocol |
+--------------------------------------+--------------------+
+-----------------------------------------------------------+
| Security Extension Module |
+--------------------------------------+--------------------+
| Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 |
| Remote, client/server authentication | GSS v5 |
| Certification services | PKIX certification |
| | protocol |
+--------------------------------------+--------------------+
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.
此模块允许经纪人与客户、供应商和其他经纪人执行电子支付操作。此类操作可在GAIA交易、搜索、定位、订购或交付行动的任何阶段进行。
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.
GAIA标准没有规定经纪人使用的加税或收费模式；这被认为是内部事务。然而，当汇票获得同意时，付款必须以双方都能接受的安全方式进行。GAIA标准中规定的付款程序使用了设定的规范。
The Payment Extension Module requires a Broker to support SET v1.0 merchant's server and SET certification protocol, specified in [18].
支付扩展模块要求代理支持SET v1.0商户服务器和SET认证协议，如[18]所述。
+----------------------------------------------------+
| Payment Extension Module |
+------------------------+---------------------------+
| Payment | SET v 1.0 : |
| | 1) CA server for banks |
| | 2) Cardholder wallet |
| | 3) Merchant Server |
| | 4) Payment Gateway server |
+------------------------+---------------------------+
+----------------------------------------------------+
| Payment Extension Module |
+------------------------+---------------------------+
| Payment | SET v 1.0 : |
| | 1) CA server for banks |
| | 2) Cardholder wallet |
| | 3) Merchant Server |
| | 4) Payment Gateway server |
+------------------------+---------------------------+
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].
- 基于SMTP协议[8]和RFC 822[9]中指定的邮件数据格式的Internet电子邮件。代理应该能够生成和发送电子邮件。-[19]中规定的SMS（短消息服务）。
+-----------------------------------------------------+
| Alerting Extension Module |
+-----------+-----------------------------------------+
| Alerting | Internet e-mail [SMTP,RFC822] (sender), |
| | SMS |
+-----------+-----------------------------------------+
+-----------------------------------------------------+
| Alerting Extension Module |
+-----------+-----------------------------------------+
| Alerting | Internet e-mail [SMTP,RFC822] (sender), |
| | SMS |
+-----------+-----------------------------------------+
The Customer Discovery Extension Module allows Z39.50 clients to use the service of the GAIA Broker.
客户发现扩展模块允许Z39.50客户端使用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:
此扩展模块要求代理支持Z39.50协议的服务器部分，如[5]中所定义。需要协议的以下子集：
- Init, Search, and Present services - GRS-1 record syntax
- 初始化、搜索和呈现服务-GRS-1记录语法
Z39.50 protocol PDUs should be carried using TCP/IP network protocols.
Z39.50协议PDU应使用TCP/IP网络协议进行传输。
+----------------------------------------------------+
| Discovery Extension Module |
+------------------------+---------------------------+
| Searching, | Z39.50 (server) |
| Locating | |
+------------------------+---------------------------+
+----------------------------------------------------+
| Discovery Extension Module |
+------------------------+---------------------------+
| Searching, | Z39.50 (server) |
| Locating | |
+------------------------+---------------------------+
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
出于一致性目的，GAIA标准规定的FUMs和FUs之间的所有接口都分为GAIA接口模块。建议GAIA代理支持这些模块，但它们不是强制性的。经纪人可以选择
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].
功能单元接口的完整规范见GAIA标准[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 |
+--------------------+------------------------------------+
+--------------------+------------------------------------+
| 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 |
+--------------------+------------------------------------+
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.
我们希望向GAIA联盟的所有成员表示感谢，感谢他们在GAIA标准的设计过程中进行了非常活跃的讨论，并提供了宝贵的直接和间接投入。
Security issues related to the electronic brokerage are discussed in Sections 2.1.4, 2.3 and 5.4.5.
第2.1.4、2.3和5.4.5节讨论了与电子经纪相关的安全问题。
[1] GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)", December 1998, see also <http://www.syspace.co.uk/GAIA/>.
[1] GAIA Consortium，可交付成果0403，“GAIA标准（最终版）”，1998年12月，另见<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>.
[2] 对象管理组，“CORBA 2.0规范”，1996年7月，见<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.
[3] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[4] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[4] Berners Lee，T.和D.Connolly，“超文本标记语言-2.0”，RFC 18661995年11月。
[5] ANSI/NISO Z39.50-1995 or ISO 23950 "Information Retrieval: Application Service Definition and Protocol Specification".
[5] ANSI/NISO Z39.50-1995或ISO 23950“信息检索：应用服务定义和协议规范”。
[6] ISO 10161:1997 "Information and documentation -- Open Systems Interconnection -- Interlibrary Loan Application Protocol Specification".
[6] ISO 10161:1997“信息和文件——开放系统互连——馆际互借应用协议规范”。
[7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[7] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[8] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[8] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[9] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[10] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[10] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
Freed，N.，Klensin，J.，和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，RFC 20481996年11月。
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[11] ISO/IEC IS 13818 "Information technology -- Coding of moving pictures and associated audio information"
[11] ISO/IEC IS 13818“信息技术——运动图像和相关音频信息的编码”
Part 1: Systems Part 2: Video Part 3: Audio Part 4: Conformance testing Part 5: Software simulation
第1部分：系统第2部分：视频第3部分：音频第4部分：一致性测试第5部分：软件模拟
[12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[12] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[13] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[13] Hoffman，D.，Fernando，G.，Goyal，V.和M.Civanlar，“MPEG1/MPEG2视频的RTP有效载荷格式”，RFC 2250，1998年1月。
[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>.
[14] Freier，A.，Karlton，P.和P.Kocher，“SSL协议-3.0版”，正在进行的工作，传输层安全工作组，1996年11月，见<http://home.netscape.com/eng/ssl3/index.html>.
[15] PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993.
[15] PKCS#7：加密消息语法标准。1.5版，1993年11月。
[16] Linn, J., "Generic Security Service Application Program Interface", RFC 1508, Geer Zolot Associate, September 1993.
[16] 林恩，J.，“通用安全服务应用程序接口”，RFC 1508，Geer Zolot Associate，1993年9月。
[17] Public-Key Infrastructure (X.509) IETF Working Group, <http://www.ietf.org/html.charters/pkix-charter.html>, July 98.
[17] 公开密钥基础设施（X.509）IETF工作组<http://www.ietf.org/html.charters/pkix-charter.html>，1998年7月。
[18] "SET Secure Electronic Transaction Specification", Version 1.0, MasterCard and Visa, May 97.
[18] “设置安全电子交易规范”，1.0版，万事达卡和Visa卡，1997年5月。
[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.
[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.translate error, please retry
Mikhail Blinov Computer Science Department University College Dublin Belfield, Dublin 4, Ireland
米哈伊尔·布利诺夫计算机科学系都柏林贝尔菲尔德大学学院，都柏林4号，爱尔兰
Phone: +353 1-706-2488
Fax: +353 1-269-7262
EMail: mch@net-cs.ucd.ie
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
米哈伊尔·贝索诺夫计算机科学系都柏林贝尔菲尔德大学学院，都柏林4号，爱尔兰
Phone: +353 1-706-2488
Fax: +353 1-269-7262
EMail: mikeb@net-cs.ucd.ie
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
Phone: +353 1-706-2488
Fax: +353 1-269-7262
EMail: ciaranc@net-cs.ucd.ie
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。