rfc2552.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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