idnits 2.17.1 draft-rfced-info-blinov-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 73 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1998) is 9323 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Functional' on line 332 -- Looks like a reference, but probably isn't: 'Customer' on line 659 -- Looks like a reference, but probably isn't: 'Alerting' on line 524 -- Looks like a reference, but probably isn't: 'Payment' on line 524 -- Looks like a reference, but probably isn't: 'Discrete' on line 533 -- Looks like a reference, but probably isn't: 'Delivery' on line 534 -- Looks like a reference, but probably isn't: 'SMTP' on line 1140 -- Looks like a reference, but probably isn't: 'RFC822' on line 1140 == Unused Reference: '4' is defined on line 1220, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (ref. '3') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 1866 (ref. '4') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 821 (ref. '8') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '9') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1889 (ref. '12') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1508 (ref. '16') (Obsoleted by RFC 2078) Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES JULY 199 INTERNET DRAFT 3 Network Working Group M. Blinov 4 M. Bessonov 5 Category: Informational C. Clissmann 6 Teltec UCD-CS 7 Ireland 8 October 1998 10 Generic Architecture for Information Availability 11 13 Status of This Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 30 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 31 (US West Coast). 33 Distribution of this document is unlimited. 35 Copyright Notice 37 Copyright (C) The Internet Society (1998). All Rights Reserved. 39 Abstract 41 This memo introduces a domain and supplier independent generic 42 architecture for the information brokerage, designed as a part of the 43 ACTS project GAIA (Generic Architecture for Information 44 Availability). 46 1. Introduction 48 Nowadays a large number of goods and services are offered on the 49 electronic market by a huge and growing number of suppliers. However, 50 there is still no efficient way for a customer to find a product or 51 information, he/she is interested in, and a supplier that can provide 52 it. Customers and suppliers already can not deal with so much 53 available information by themselves. High heterogeneity of existing 54 protocols, formats and underlying networks also limits development of 55 the electronic market. 57 This results in a demand for brokerage systems, which can work as 58 intermediary entities between customers and content suppliers. 59 Brokerage systems assist a customer during the trading process and 60 hide heterogeneity and distribution of information from the customer. 61 The design of domain and supplier independent generic architecture 62 for such brokerage systems is an objective of the project GAIA 63 (Generic Architecture for Information Availability). GAIA received 64 part-funding from the EU's ACTS programme for Research and 65 Technological Development. The GAIA brokerage system allows a 66 customer to 67 - search for a particular "product" (information, content or services), 68 which he/she is interested in 69 - locate the product, i.e. find supplier(s), 70 from which this product is available 71 - order the product from the supplier 72 - receive delivery of the product by digital means 74 All these actions are carried out by the broker according to requests 75 of the customer. Broker services are accessible to the customer 76 through the unified user interface. The customer system does not have 77 to support all the protocols involved in the trading process. 79 Full specification of the GAIA Architecture is available in the GAIA 80 Standard [1]. The GAIA Standard includes a description of the GAIA 81 Reference Model, GAIA Functional Architecture, GAIA Standard Profiles 82 and specification of the GAIA interfaces. 84 This memo does not aim to include the whole text of the GAIA Standard, 85 but to present basic ideas and concepts of this standard. 87 The structure of this memo follows the structure of the GAIA Standard: 89 1. The GAIA Reference Model, which provides a common basis for the 90 description and specification of brokerage systems, including the 91 GAIA system. 93 2. The GAIA Functional Architecture, which defines functional 94 elements of the GAIA Broker, their roles and relationships. 96 3. The GAIA Brokerage System Interfaces, which describes internal and 97 external interfaces of the GAIA brokerage system. 99 4. The GAIA Standard Profiles, which specifies mandatory and optional 100 profiles to which brokerage systems may conform. 102 2. The GAIA Reference Model 104 The Generic Architecture for Information Availability (GAIA) 105 Reference Model outlines the operations and actors involved in 106 finding, ordering and delivering physical and digital objects and 107 services ("Products") in a global brokered distributed information 108 environment. It provides an overall view of the GAIA environment, and 109 illustrates the respective roles of and relationships between its 110 components. Further work on standards and frameworks for individual 111 components of the GAIA environment uses the model and terminology 112 provided by the Reference Model. 114 The GAIA environment is a collection of actors and functions that are 115 combined to support a procedure for information and services 116 discovery, order and delivery. The actors play roles in the 117 procedure, including initiation and execution of the Actions which 118 are combined to make up the overall transaction. The GAIA 119 architecture provides a standardised and widely applicable framework 120 for the provision and implementation of the brokered search and 121 retrieve applications in a large-scale networked environment. 123 2.1. GAIA Roles 125 The GAIA model considers three principal roles, which can be played 126 by the GAIA actors. These are the Customer, the Broker and the 127 Supplier. These Roles are shown in the Figure 1 below. It also 128 considers a further class of active entities, who play supporting 129 roles in the Actions. This latter class is known as GAIA "Helpers" 130 and includes, for example, authentication and payment. The actors are 131 organisations and individuals in the supply chain. Every GAIA actor 132 plays at least one role at any given time. 134 2.1.1. The Customer 136 The aim of the Customer is to obtain some Products or information 137 about some Products. The Customer role initiates the GAIA transaction 138 by requesting one or more GAIA Actions, and receives the results of 139 the transaction. The Customer may deal with actors playing either of 140 the other two roles, the Broker or the Supplier. These actors may 141 themselves play the role of the Customer while requesting further 142 services from other Brokers. 144 2.1.2. The Broker 146 The Broker provides brokerage services to the Customer and the 147 Supplier. It responds to requests from the Customer to provide 148 Products, or information about Products. The Products that the Broker 149 supplies to the Customer may originate from one or more Suppliers 150 and/or Brokers. The Broker's primary role is to act as a collector 151 and collator of information from a number of different Suppliers, and 152 to supply this information to the Customer, thus obviating the need 153 for the Customer to deal with a variety of Suppliers. A Broker can 154 also be considered to act on behalf of a Supplier, distributing 155 information about the Products available. The actor playing the role 156 of the Broker may play the role of a Supplier to a Customer or other 157 Broker at the same time. The Broker may play the role of a Customer 158 while interacting with another Broker or with a Supplier. 160 2.1.3. The Supplier 162 The Supplier is the source of the Product supplied to the Customer. 163 The Supplier provides the Broker with information about the Product 164 that it can supply. The Supplier may supply its Product directly to 165 the Customer, or to the Broker, for forwarding to the Customer. An 166 actor playing the role of a Supplier may also play the role of a 167 Broker. A Supplier may deal with a large number of Brokers and 168 Customers, over a number of GAIA transactions. 170 2.1.4. Helpers 172 A Helper is an application layer entity playing a supporting role in 173 a GAIA transaction. Helpers provide some service needed in the supply 174 chain, but outside the core functionality of the Broker. Examples 175 include a global directory service or payment service or 176 authentication service. 178 The authentication Helper is concerned with facilitating the 179 authentication of one actor to another. 181 The payment Helper is concerned with supporting a mechanism for 182 payment to one actor by another. 184 In any given GAIA transaction, there will be one or more Customers 185 (usually one), one or more Brokers, and one or more Suppliers. A 186 description of the Product sought by the Customer is provided by the 187 Customer to the Broker. The Broker may involve other Brokers in the 188 search for the Product. When a Supplier of the Product is discovered 189 by the Broker, this information is included in the response of the 190 Broker to the Customer. During the course of the Action, it may be 191 necessary to call upon the services of one or more Helpers. 193 2.2. GAIA Actions 195 Each GAIA transaction is made up of one or more Actions. These 196 Actions are requests by the Customer to the Broker or the Supplier to 197 carry out some operation, and to respond to the Customer. Four 198 Actions are defined 200 - Search 201 - Locate 202 - Order 203 - Deliver 205 These Actions are shown in the Figure 1. 207 +--------+ . . +--------+ . . +-----------+ 208 | |-- Search -->| |-- Search -->| |+ 209 | | : : | | : : | || 210 | |-- Locate -->| |-- Locate -->| || 211 |Customer| : : | Broker | : : |Supplier(s)|| 212 | |-- Order --->| |-- Order --->| || 213 | | : : | | : : | || 214 | |<- Deliver --| |<- Deliver --| || 215 +--------+ : : +--------+ : : +-----------+| 216 : : : : +-----------+ 217 Helpers Helpers 218 220 Figure 1 GAIA Roles and Actions 222 2.2.1. Search 224 The Search Action is carried out when the Customer asks the Broker to 225 find some information on its behalf. In order to do this, the 226 Customer provides the Broker with some description of the Product 227 which it requires. On the basis of this description, the Broker 228 carries out a search on behalf of the Customer and returns the result 229 to it. The result of a Search Action is a set of unique identifiers 230 referencing the Products matching the description provided by the 231 Customer. 233 2.2.2. Locate 235 The Locate Action is carried out when the Customer asks the Broker to 236 provide it with information regarding the location and source of some 237 Product. In order to allow the Broker to do this, the Customer 238 provides an unambiguous identification of the Product, which may be 239 the result of a Search Action. The Broker returns information to the 240 Customer about a source or sources for the Product. These data 241 include the Terms of Availability information such as methods of 242 delivery available, time of delivery, costs, etc. However, this 243 information can not be considered final, since some special terms and 244 conditions may apply, e.g. discounts for some categories of 245 Customers. The final version of the Terms of Availability is 246 established during the negotiation phase of the Order Action. 248 2.2.3. Order 250 The Order Action is carried out when the Customer asks the Broker to 251 obtain a Product on its behalf, or asks the Supplier to sell the 252 Product directly to the Customer. To enable Order, the Customer 253 provides the Broker/Supplier with Product source information, which 254 may be a result of a Locate Action. The Order Action consists of a 255 negotiation phase and (possibly) a purchase phase. During the 256 negotiations phase the Customer obtains the quotation which contains 257 the final version of the Terms of Availability for the (batch of) 258 Products he is considering purchasing. If the Customer finds these 259 conditions satisfactory, he commits to the purchase. Alternatively if 260 the Broker or Supplier supports telepresence services for the human 261 interaction with the Supplier or Broker representatives, these may be 262 used during the negotiations. 264 2.2.4. Deliver 266 The Deliver Action is carried out when the Broker provides the 267 Customer with some requested Product. The Product may be information, 268 some physical object or metadata. The Deliver Action may be in 269 response to an Order Action, a Search Action or a Locate Action. 271 While the Actions presented in this section may logically be taken to 272 form an integrated sequence, this is not necessarily the case. 273 Actions may take place independently, rather than as a part of a 274 four-Action whole. For example, Order and Deliver Actions may occur 275 on the basis of information obtained by the Customer using some other 276 mechanism than GAIA Search and Locate Actions. 278 2.3. GAIA Helper Events 280 During any of the GAIA Actions outlined above, it may be necessary to 281 carry out some supporting activity. These activities are called GAIA 282 Helper events. They include, for example, authentication and payment. 283 The Helper entities are involved in the GAIA events to provide 284 services, additional to the GAIA Actions, to the GAIA actors. 286 Authentication 288 In order to verify the identity of one GAIA actor to another, an 289 authentication exchange may need to take place. This may occur during 290 any of the GAIA Actions. The manner or method of authentication is 291 outside the scope of this document. 293 Payment 295 It may be necessary for payment to take place during a GAIA 296 transaction. In this situation, one GAIA actor pays one or more 297 other GAIA actors. The manner or method of payment is outside the 298 scope of this document. 300 Security 302 As part of any GAIA Action, it may be necessary to carry out some 303 security operations, such as encryption of data, verification of 304 source and content integrity of Product, or digital signature of some 305 data entity or entities. The particular security services and 306 mechanisms which may be required, or the manner, in which they may be 307 provided, is outside the scope of this document. 309 3. The GAIA Functional Architecture 311 3.1. The Concept 313 The GAIA Functional Architecture decomposes the overall functionality 314 of the GAIA Broker into a number of components, and describes the 315 roles and relationships of the components, and the manner in which 316 they interoperate. 318 In order to work in a heterogeneous environment the GAIA Functional 319 Architecture introduces three levels of abstract elements of the 320 Broker: the Kernel, Functional Unit Managers (FUMs), and Functional 321 Units (FUs) (see Figure 2). 323 GAIA Broker: 324 ------------ 325 [ Kernel ] Kernel 326 / \ level 327 / \ 328 [Functional Unit] [Functional Unit] Technology-independent 329 [ Manager ] [ Manager ] action-dependent 330 / \ / \ level 331 / \ / \ 332 [Functional][Functional] [Functional][Functional] Technology 333 [Unit ][Unit ] [Unit ][Unit ] dependent 334 level 336 Figure 2 Levels of the architecture 338 Functional Units are the technology dependent parts of the 339 architecture. They perform required transactions in terms of a 340 particular protocol. All FUs are covered by a technology-independent 341 interface. FUs are grouped according to the trading action they 342 participate in, e.g. search FUs or locate FUs. Each group of FUs is 343 governed by the corresponding Functional Unit Manager. 345 Functional Unit Managers contain technology independent functions for 346 particular actions. In order to use a particular technology FUM uses 347 the services of attached FUs. There may be several FUs associated 348 with a FUM, allowing the FUM to operate in different technology 349 contexts. There is one FUM in the system for every area of 350 functionality, e.g. search, locate, order. The Kernel is responsible 351 for managing the activity of different FUMs (corresponding to 352 different actions) and synchronising events between them. 354 The GAIA Functional Architecture establishes relationships between 355 the existing technologies (standards and protocols) that are combined 356 in the GAIA Standard, in the context of a brokerage system. It is to 357 be expected that new technologies will evolve which will be viable 358 alternatives to those selected. The abstract and modular nature of 359 the Functional Architecture allows the replacement of one technology 360 with a new one without disruption to the rest of the brokerage 361 system. 363 3.2. Functional Units 365 The brokerage system provides a number of services to its users. 366 These services are supported by the functions of the brokerage 367 system. These include, for example, 369 - searching 370 - ordering 371 - payment 373 Each of these functions can be provided by a number of different 374 candidate technologies. However, the operations that are required to 375 be carried out remain the same - regardless of the selected 376 technologies, the functional requirements do not change. The required 377 operations are described in terms of abstract primitives, which can 378 be mapped to the protocol instructions of the technology selected to 379 support the function. A mapping component, called a Functional Unit 380 (FU), is defined for each candidate technology, and converts calls to 381 abstract primitives into protocol instructions. The FU acts as an 382 adaptor between its particular technology and the rest of the 383 brokerage system. 385 Functional Units are defined for each candidate technology that can 386 be used to fulfil a particular functional need of the brokerage 387 system. A Functional Unit accepts abstract primitive invocations, and 388 maps them to calls to the particular technology to which it is 389 dedicated. The results of these calls are translated into the 390 corresponding abstract primitives and returned by the FU, as shown in 391 the Figure 3. 393 * The rest of the Broker * 394 ^ 395 | -abstract primitives 396 v 397 +------------+ 398 | Functional | 399 | Unit | 400 +------------+ 401 ^ 402 | -technology-specific commands 403 v 404 * Technology functions * 406 Figure 3 GAIA Functional Unit 408 3.3. Functional Unit Managers 410 As noted above, a number of different candidate technologies can be 411 used to fulfil a particular functional requirement of the brokerage 412 system. Depending on the details of the GAIA transaction (underlying 413 network, Customer system capabilities, etc.), different technologies 414 may be more useful during different transactions. As a result, each 415 candidate technology has its own Functional Unit, which is invoked 416 when that particular technology is required. 418 A number of different Functional Units can exist which fulfil the 419 same functional requirement of the brokerage system. In order to 420 select the most appropriate FU (and technology), the brokerage system 421 needs to know which is the most useful at any particular time, 422 generally the one supported by the target Supplier system. This is 423 the responsibility of the Functional Unit Manager, or FUM. Each 424 function of the brokerage system has a single FUM, which is invoked 425 in terms of abstract primitives by the Broker Kernel. This FUM 426 selects the most appropriate of the candidate technologies, and calls 427 the corresponding FU (see Figure 4). 429 The interface between the FUM and the corresponding FUs is defined 430 for every FUM in an open, platform independent and programming 431 language independent manner. These interfaces do not depend on any 432 particular technology. It allows configuring the set of technologies, 433 supported by the Broker, by attaching different subsets of FUs. If a 434 new technology is to be supported by a Broker, a new FU implementing 435 this technology can be created according to the specification of the 436 interface and attached to the corresponding FUM. 438 +--------------------------------------+ 439 | Functional Unit Manager | 440 +--------------------------------------+ 441 ^ ^ 442 | -abstract primitives- | 443 v v 444 +------------+ +------------+ 445 | Functional | | Functional | 446 | Unit | | Unit | 447 +------------+ +------------+ 448 ^ ^ 449 | -technology-specific commands- | 450 v v 451 * Technology * * Technology * 452 * functions * * functions * 454 Figure 4 Functional Unit Manager 456 3.4. The Kernel 458 The Kernel of the brokerage system acts as a bus for the transmission 459 of abstract primitives between FUMs. Each FUM imports a set of 460 abstract primitives, representing those services which the FUM 461 expects to receive from some other part of the system. The services 462 that the FUM is prepared to provide to other elements of the 463 brokerage system are presented in the form of exported abstract 464 primitives. All these abstract primitives are imported from, and 465 exported to, the Kernel (see Figure 5). 467 The Kernel is also responsible for synchronisation of different 468 actions within a transaction and for maintaining a common context 469 between actions. 471 +-------------------------------------+ 472 | Broker Kernel | 473 +-------------------------------------+ 474 ^ ^ ^ 475 | -abstract- | -primitives- | 476 v v v 477 +-------+ +-------+ +-------+ 478 | FUM | | FUM | | FUM | 479 +-------+ +-------+ +-------+ 481 Figure 5 Broker Kernel 483 3.5. Description of FUMs 485 The core activities of the brokerage system include: 487 1. searching for Products that fit a user description 488 2. sourcing Products the identification of which is known 489 3. allowing users to order Products 490 4. delivering information in item format 491 5. delivering information as a continuous media stream 492 6. providing a user interface to the brokerage services 493 7. alerting users as to the availability of information 494 8. interacting with external directory services 495 9. authentication of other actors 496 10. payment operations 498 Each of these activities is carried out by the corresponding FUM as 499 described below and shown in the Figure 6. 501 Search FUM 503 The Search FUM accepts requests to carry out a search for Products 504 that fit a particular user description. It returns lists of 505 identifiers of Products that fit the description. 507 Locate FUM 509 The Locate FUM accepts Product identifiers, and discovers where they 510 may be obtained. It returns lists of Suppliers and locations for the 511 Product. 513 Order FUM 515 The Order FUM manages negotiations between a Customer and a Supplier, 516 in order that agreement may be reached on the terms of availability 517 of a particular Product or group of Products. Following the 518 The GAIA Broker: 519 ---------------- 520 (Customer)) (Alerting)) ( DS )) (Auth)) (Payment)) 521 ( FUs )) ( FUs )) ( FUs )) ( FUs)) ( FUs )) 522 (e.g.HTTP)) (e.g. SMS)) (eg LDAP)) ( )) (e.g.SET)) 523 \/ \/ \/ \/ \/ 524 [Customer] [Alerting] [ DS ] [ Auth ] [Payment] 525 [ FUM ] [ FUM ] [ FUM ] [ FUM ] [ FUM ] 526 | | | | | 528 +----------------------------------------------------------+ 529 | Broker Kernel | 530 +----------------------------------------------------------+ 531 | | | | | 533 [ Search ] [ Locate ] [ Order ] [ Stream ] [Discrete] 534 [ FUM ] [ FUM ] [ FUM ] [Delivery] [Delivery] 535 [ ] [ ] [ ] [ FUM ] [ FUM ] 536 /\ /\ /\ /\ /\ 537 ( Search )) ( Locate )) ( Order )) ( SD )) ( DD )) 538 ( FUs )) ( FUs )) ( FUs )) ( FUs )) ( FUs )) 539 (eg Z39.50)) (eg Z39.50)) (eg ISO ILL)) (eg RTP)) (eg FTP)) 541 Figure 6 GAIA Functional Architecture 543 negotiation phase, the Order FUM accepts purchase commitments from 544 the Customer and forwards them to the Supplier. It returns a 545 notification of the status of the Order Action. 547 Discrete Delivery FUM 549 The Discrete Delivery FUM manages the delivery of discrete items to 550 the Customer. 552 Stream Delivery FUM 554 The Stream Delivery FUM manages the delivery of real-time multimedia 555 data streams to the Customer. 557 Customer FUM 559 The Customer FUM provides an interface to support the Customer's 560 systems interaction with the brokerage system. 562 Alerting FUM 563 The Alerting FUM notifies Customers about changes that may interest 564 them. 566 Directory Services FUM 568 The Directory Services FUM provides an interface between an external 569 directory service and the brokerage system. 571 Authentication FUM 573 The Authentication FUM provides a mechanism that allows a user to 574 prove his identity to the brokerage system. 576 Payment FUM 578 The Payment FUM provides a mechanism for payment from one actor to 579 another. 581 4. GAIA Brokerage System Interfaces 583 This Chapter describes internal and external interfaces of the GAIA 584 brokerage system. 586 4.1. Internal Interfaces 588 The definition of communications between functional components within 589 the GAIA Broker is based on the OMG CORBA model [2]. Interfaces 590 between components are defined on the IDL language, specified by OMG. 591 Interface calls are passed between components by the Object Request 592 Broker (ORB). 594 The advantage of this approach is that the specifications of the 595 interfaces are platform and programming language independent. These 596 interfaces can be implemented using different programming languages 597 on different platforms. All necessary conversions during interface 598 invocations are transparently performed by an ORB. The CORBA model 599 also allows installing different functional components of the GAIA 600 Broker on different computers connected by a network. Interface calls 601 will be transferred over the network by an ORB transparently for the 602 application. 604 The specification of the interfaces between the Kernel and FUMs and 605 between each FUM and corresponding FUs is presented in the GAIA 606 Standard [1]. 608 4.2. External protocols 610 The GAIA Broker can use existing protocols to communicate with other 611 actors. For example, it can use HTTP for interactions with Customers, 612 Z39.50 for search, etc. As described in the GAIA Functional 613 Architecture, support of particular technologies is provided by FUs. 614 A set of supported protocols can be extended by attaching 615 corresponding new FUs to a Broker. The GAIA Broker can support 616 several protocols for each action. FUMs will select the most 617 appropriate protocol for a transaction. The more protocols are 618 supported by the Broker, the better service it can provide to 619 Customers and Suppliers. 621 The GAIA Standard does not limit the set of protocols supported by 622 the Broker. However, for the purpose of interoperability, it 623 specifies several GAIA profiles. These profiles aim to define the 624 common subset of protocols (and a common range of protocol 625 parameters), which is encouraged to be supported by Brokers in order 626 to make possible communications between GAIA Brokers and with GAIA- 627 aware Suppliers and Customers. 629 Existing protocols are not the only way to contact the GAIA Broker. 630 The GAIA interfaces have been designed as a generalisation of 631 existing interfaces and protocols, so they provide more functionality 632 than any particular protocol. In order to give access to full 633 functionality of the GAIA Broker, the GAIA Standard allows users 634 (Customers and other Brokers) to use directly the CORBA-defined 635 Customer interface of the GAIA Broker (interface between Customer FUM 636 and FUs) as shown in Figure 7. In this case the Customer system gets 637 access to the Customer interface of the Broker using the service of 638 an underlying ORB, and can request operations by calling 639 corresponding methods of the interface. The Customer interface of 640 the GAIA Broker is specified in the GAIA Standard [1]. 642 Where Customer and Supplier systems are not CORBA-aware, they can 643 communicate with a GAIA Broker using existing protocols. If, however, 644 they can use the service of an ORB, they are encouraged to 645 communicate with a Broker by connecting to its Customer interface. 646 This method allows avoiding convergence between a particular protocol 647 and the GAIA interface. The former way makes possible interactions 648 with all existing types of Customer and Suppliers, using existing and 649 widespread protocols. The later way has been designed to archieve 650 maximum functionality by using native GAIA methods for communications 651 with Customers and Suppliers. 653 +----------------+ 654 |Broker | 655 | | 656 -------- 657 +-----------+ | [ Kernel ] | 658 | Broker | | -------- | 659 | or | | [Customer] | 660 | Customer | | [ FUM ] | 661 | | | ========== <-GAIA Customer 662 | * | | * * | \interface 663 | { O R B *}* * * * * * *{* O R B * } | 664 +-----------+ iiop | * | +----------+ 665 | (Customer) | | Customer | 666 | ( FU ) | | | 667 +------------I---+ +----I-----+ 668 \ HTTP / 669 - - - - - - 671 Figure 7 External protocols and the GAIA Customer interface 673 5. GAIA Standard Profiles 675 The GAIA Standard defines a number of profiles, which a Broker may 676 support in order to achieve interoperability with other GAIA actors 677 (Customers, Suppliers and other Brokers). The complexity of the 678 profile chosen by a Broker depends on the level and type of service 679 which the Broker wishes to deliver in a GAIA-conformant manner. The 680 higher the level of service which a Broker provides to a Customer, 681 and the greater the length of the supply chain which the Broker 682 wishes to support, the more advanced the profile, and/or the greater 683 the number of extension modules the Broker must support. 685 5.1. Supply Chains 687 The GAIA profile definition approach is based on the possible types 688 of supply chains, which a brokerage system can be a part of. 690 The operations of a brokerage system can be broken into three 691 categories: 693 - interactions with the Customer 694 - interactions with other Brokers 695 - interactions with Suppliers 697 The first and last of these occur at the two ends of a supply chain, 698 while inter-broker operations take place at other points in the 699 chain. The supply chain may take a number of different forms: 701 - a minimal chain, where the Customer and the Broker are the ends of 702 the chain, and there are no intervening links. In this case, the 703 Broker plays the role of Supplier to the Customer. 705 - a three-piece chain, where the Broker deals with the Customer and 706 the Supplier, but not with any other Broker. 708 - a longer chain, with one or more inter-broker operations. 710 Minimal Supply Chain: 711 +--------+ +-------------+ 712 |Customer| <=====> | Broker | 713 +--------+ |(as Supplier)| 714 +-------------+ 715 3-piece Supply Chain: 716 +--------+ +--------+ +--------+ 717 |Customer| <===> | Broker | <===> |Supplier| 718 +--------+ +--------+ +--------+ 719 Longer Supply Chain: 720 +--------+ +--------+ +--------+ +--------+ 721 |Customer| <===> | Broker |<=>| Broker | <===> |Supplier| 722 +--------+ +--------+ +--------+ +--------+ 724 Figure 8 Supply Chains 726 5.1.1. Minimal Supply Chains 728 As discussed in the GAIA Reference Model, a GAIA transaction is 729 composed of a number of actions, such as search, order and delivery. 730 Each transaction is initiated by the Customer, who makes a request to 731 the Broker. In the event that the Broker is able to fulfil the 732 request, the transaction involves no other actors. 734 In this simple case, the GAIA transaction involves the Customer and 735 the Broker, and the only protocol which needs to be standardised is 736 that between the Customer and the Broker. This is specified in the 737 GAIA Standard Minimal profile, below. 739 5.1.2. Longer Supply Chains 741 In the event that the Broker is not able to fulfil a request, the 742 action may be propagated on to other Brokers, with the original 743 Broker playing the Customer role. Each of these Brokers may in their 744 turn propagate the request, if they cannot fulfil it. 746 Eventually, if the action is successful, a Supplier will be found who 747 can fulfil the request. The supply chain is thus made up a single 748 Customer, one or more Suppliers, and one or more Brokers. 750 In order to propagate an action from one Broker to another, a 751 standardised communication protocol must be defined for broker-broker 752 interaction. This is specified in the Basic profile, below. This 753 profile is based on CORBA. 755 Supplier and Brokers, however, are not obliged to support the Basic 756 profile of the GAIA Standard. They may instead use another, more 757 traditional, protocol, such as Z39.50 for discovery or ISO ILL for 758 ordering. The Extension Modules to the GAIA Standard specify the 759 profiles to be used for various brokerage functions. 761 5.2. Introduction to the GAIA Standard Profiles and Modules 763 The profiles specified are 765 - The Minimal profile, which is the very least 766 to which a GAIA Broker must conform 767 - The Basic Profile, which allows inter-broker communication 768 - A number of Extension Modules, which allow the Broker 769 to provide various services, and to interoperate with Suppliers, 770 Brokers and Customers using protocols specified in the modules 771 - A set of Interface Modules, that defines which particular 772 Functional Unit CORBA interfaces are supported by the Broker 774 Each Broker must conform at least to the Minimal profile to provide a 775 web-based user interface. In addition, in order to take part in 776 inter-broker communications, the Basic profile is recommended. For 777 interaction with non-CORBA-aware entities, and for the use of 778 advanced services, there are other modules of the standard to which 779 the Broker may conform. These are denoted "Extension Modules", and 780 they characterise the protocols and standards in a particular area of 781 functionality. A Broker can choose an appropriate set of Extension 782 Modules to conform to according to the functionality it wishes to 783 achieve. 785 The GAIA Standard specifies all interfaces between FUM and FUs for 786 the GAIA Broker. However, it would be too much to require every 787 Broker to implement all of them. The GAIA Standard decomposes all 788 interfaces into a number of Interface Modules. A Broker can choose a 789 subset of Interface Modules, which is more important in its area of 790 operation, and implement interfaces defined in these modules. These 791 interfaces are important only inside the broker system and do not 792 play any role in communication with other GAIA actors. However, a 793 declaration of supported interfaces is important for the 794 administrator to find in which areas the functionality of the Broker 795 can be extended by attaching GAIA-conformant FUs. 797 5.3. Minimal Profile 799 The minimum functionality that a Broker must support will allow it to 800 provide services to the Customer as a part of a minimal chain. In 801 this case, what is required of the Broker is simply a user interface 802 for the Customer. Any further operations take place within the 803 Broker, and so do not come within the scope of the standard. 805 The Minimal profile requires the Broker to implement a user interface 806 based on the HTTP 1.1 protocol, defined in RFC 2068 [3], and HTML 807 2.0, defined in RFC 1866 [5]. It means that a Customer should be able 808 to access the basic functionality of the GAIA Broker by using an HTTP 809 1.1 and HTML 2.0 -conformant web-browser. 811 It should be possible for Customers to locate a GAIA Broker. Thus a 812 GAIA Broker should be registered in a Directory Service using a 813 schema specified in the GAIA Standard [1]. 815 +-------------------------------------------------+ 816 | Minimal Profile | 817 +------------------------+------------------------+ 818 | Customer | HTTP 1.1 (server), | 819 | | HTML 2.0 | 820 +------------------------+------------------------+ 822 5.4. Basic Profile 824 While the minimal functionality is sufficient to allow a Broker to 825 function, an important aspect of any GAIA Broker functionality is 826 dealing with other Brokers. The goal of the Basic profile is to 827 achieve federation between Brokers. Every GAIA Broker can use the 828 service of other GAIA Brokers in order to fulfil a request of a 829 Customer. That Broker in turn can use the service of the third GAIA 830 Broker. So every request can be chained by several Brokers. This 831 extends the abilities of every GAIA action (Search, Locate, Order, 832 etc.). Chained transactions are particularly important in the 833 discovery phase of a transaction, where a Broker unable to fulfil a 834 particular information requirement, passes on the search to another 835 Broker. 837 The Basic profile requires the Broker to implement the GAIA Customer 838 interface defined in terms of CORBA. This interface is described in 839 more detail in Section 4.2 above. The Basic profile also requires the 840 Broker to implement interface requestor procedures, i.e. to be able 841 to connect to the Customer interfaces of other Brokers. The ORB used 842 by the Broker should be conformant to the CORBA 2.0 specification [2] 843 and use IIOP protocol for inter-ORB communications [2]. 845 A full specification of the GAIA Customer interface is presented in 846 the GAIA Standard [1]. 848 A GAIA Broker should be able to find other Brokers and Suppliers. It 849 should also allow other participants to find it. Thus a GAIA Broker 850 should support a directory service. The Basic profile includes a 851 directory access protocol for this purpose. The actual choice of 852 protocol is not standardised, because the choice does not influence 853 the success of the Broker's inter-operation with other Brokers. The 854 directory schema, which should be used, is specified in the GAIA 855 Standard. 857 The Basic profile suggested for a Broker to allow it to interoperate 858 with other GAIA Brokers is as follows. 860 +----------------------------------------------------------------+ 861 | Basic Profile | 862 +------------------------+---------------------------------------+ 863 | Customer | GAIA Customer interface/IIOP (server) | 864 | Search and Locate | GAIA Customer interface/IIOP (client) | 865 | (Discovery) | | 866 | Order | GAIA Customer interface/IIOP (client) | 867 | Directory | Some directory access protocol, | 868 | | such as LDAP | 869 +------------------------+---------------------------------------+ 871 5.5. Extension Modules 873 In order to allow Brokers to interoperate with other Brokers that do 874 not support the Basic profile, and to allow Brokers to deal with 875 Suppliers and Customers who are not CORBA-aware, as well as to allow 876 delivery of items and data streams via the Broker, other open 877 technologies are suggested as extensions to the Basic and Minimal 878 profiles. These technologies reflect the results of the technology 879 evaluation carried out as part of the project GAIA. 881 The extra protocols are grouped into Extension Modules. Support of 882 these Extension Modules is optional. A Broker can choose an 883 appropriate set of Extension Modules to conform to according to the 884 functionality it wishes to achieve. There is one Extension Module for 885 each of the functional areas which are not covered by the Basic and 886 Minimal Profiles, and also one Extension Module for each of the 887 existing areas (Customer, Discovery and Order) to allow the use of 888 protocols other than GAIA abstract primitives. 890 The following Extension Modules are defined. 892 - Discovery Extension Module 893 - Order Extension Module 894 - Discrete Delivery Extension Module 895 - Stream Delivery Extension Module 896 - Security Extension Module 897 - Payment Extension Module 898 - Alerting Extension Module 899 - Customer Discovery Extension Module 901 5.5.1. Discovery Extension Module 903 The Discovery Extension Module specifies the technologies to be used 904 in searching for and locating products and services. 906 This Extension Module requires the Broker to support the client part 907 of the Z39.50 protocol, as defined in [5]. The following subset of 908 the protocol is required 910 - Init, Search, and Present services 911 - GRS-1 record syntax 913 Z39.50 protocol PDUs should be carried using TCP/IP network 914 protocols. 916 +-------------------------------------------------+ 917 | Discovery Extension Module | 918 +------------------------+------------------------+ 919 | Searching, | Z39.50 (client) | 920 | Locating | | 921 +------------------------+------------------------+ 923 5.5.2. Order Extension Module 925 The Order Extension Module specifies the protocols to be used to 926 order products and services from a Supplier. 928 This Extension Module requires the Broker to support all mandatory 929 services of the client part of the ISO ILL protocol [6]. Basic 930 conformance criteria should be adhered to. ISO ILL protocol PDUs 931 should be carried using TCP/IP network protocols. 933 +-------------------------------------------------+ 934 | Order Extension Module | 935 +------------------------+------------------------+ 936 | Order | ISO ILL (client) | 937 +------------------------+------------------------+ 939 5.5.3. Discrete Delivery Extension Module 941 The Discrete Delivery Extension Module specifies the protocols and 942 standards to be used for the delivery of on-line products and 943 services to the Customer. There are two delivery scenarios considered 945 - Direct Supplier to Customer delivery 946 The delivery may be a single-step operation, with the Supplier 947 supplying his product directly to the Customer, without the 948 involvement of any Broker in the delivery process. The Broker may 949 have acted to refer the Customer to the Supplier. In this case, 950 where the Broker is not involved in delivery, the Discrete Delivery 951 Extension Module does not apply. 953 - Delivery over a supply chain with one or more Brokers involved 954 In the event of the Broker being the central link in a supply chain 955 of the form of Supplier-Broker-Customer, the Broker will use the 956 protocols specified in the Discrete Delivery Extension Module to 957 receive the product from the Supplier, and to provide the product 958 to the Customer. 960 The Discrete Delivery Extension Module requires the Broker to provide 961 both FTP client and FTP server functionality [7], to allow the Broker 962 to receive and to transmit files using FTP. 964 The Discrete Delivery Extension Module requires the GAIA Broker also 965 to be able to accept and to generate e-mail messages. The e-mail 966 protocol specified is Internet e-mail, based on SMTP protocol [8] and 967 mail data formats specified in RFC 822 [9]. This protocol is 968 sufficient for the creation, transmission and management of textual 969 e-mail messages. However, for the transmission of data files of 970 various types, extensions to the SMTP/RFC822 protocols are required. 971 The mail extensions specified by the Discrete Delivery Extension 972 Module are based on MIME (Multipurpose Internet Mail Extensions), 973 defined in RFCs 2045-2049 [10]. Thus a GAIA Broker must be able to 974 send and receive "simple" SMTP/RFC822 mail, and also be able to deal 975 with RFC 2045-2049 MIME mail extensions. 977 For electronic document delivery the Discrete Delivery Extension 978 Module requires the support of GEDI version 3.0. 980 +--------------------------------------------------------+ 981 | Discrete Delivery Extension Module | 982 +------------------------+-------------------------------+ 983 | FTP profile | FTP (client+server) | 984 | Email profile | Internet e-mail [SMTP,RFC822] | 985 | | (receiver+sender), | 986 | | MIME | 987 | Document delivery | GEDI version 3.0 | 988 +------------------------+-------------------------------+ 990 5.5.4. Stream Delivery Extension Module 992 This Extension Module is intended to support real-time delivery of 993 multimedia by the GAIA Broker. 995 Several scenarios of stream delivery are considered. A stream can be 996 delivered 998 - directly from a Supplier to a Customer 999 The Broker does not take part in the stream delivery process, so 1000 this scenario is out of scope of this standard. 1002 - from a Supplier to a Customer via a Broker 1003 The Broker can add value to the stream delivery process by 1004 implementing cache algorithms, mixing streams, branching one stream 1005 to several Customers, etc. 1007 - from a Broker to a Customer 1008 The Broker can keep a small amount of multimedia data (e.g., audio 1009 examples) in its own database and deliver it to a Customer upon 1010 request. 1012 The Stream Delivery Extension Module is recommended to be implemented 1013 by a Broker in order to provide the last two scenarios of real-time 1014 multimedia delivery. 1016 The Stream Delivery Extension Module requires the Broker to support 1017 the following technologies 1019 - Compression 1020 MPEG-2 Audio Layer 3, specified in ISO/IEC 13818-3 [11]. Only 1021 support of constrained parameter streams (CSPS) is required. 1023 - Data transfer protocol 1024 RTP protocol over UDP/IP, defined in RFC 1889 [12] (both client and 1025 server parts). It is recommended to support full behaviour of RTP 1026 application service entity ("translator" or "mixer") but it is not 1027 required. 1029 - Mapping 1030 RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13]. 1032 - Session control protocol 1033 RTCP, specified in RFC 1889 [12]. 1035 This profile provides delivery of high quality audio over the 1036 networks with non- guaranteed quality of service such as the 1037 Internet. 1039 +----------------------------------------------------+ 1040 | Stream Delivery Extension Module | 1041 +--------------------------+-------------------------+ 1042 | Compression | MPEG-2 Audio Layer 3 | 1043 | Data transfer | RTP (client+server) | 1044 | Mapping | RFC 2250 | 1045 | Session control protocol | RTCP | 1046 +--------------------------+-------------------------+ 1048 5.5.5. Security Extension Module 1050 The basic security services required for GAIA are 1052 - Authentication 1053 of users, remote servers (both as entity authentication and as 1054 bilateral peer-to-peer authentication), authentication of senders 1055 and receivers in network transactions, as well as the 1056 authentication of documents. Authentication is required for three 1057 situations: authentication at the user workstation when starting 1058 the session, authentication in a local environment (client/server 1059 authentication) and authentication in a global, open network 1060 (Internet). 1062 - Confidentiality 1063 and integrity of all resources transferred over the network or 1064 handled locally at application servers and user workstations. 1066 - Control of access to services and resources. 1068 - Non-repudiation of transactions, participants and sensitive 1069 documents. 1071 This module allows a Broker to secure communications with other 1072 participants. It provides channel security, authentication, and 1073 certificate exchange. 1075 The Security Extension Module specifies the following protocols and 1076 algorithms 1078 - Privacy, integrity, non-repudiation 1079 SSL v3.0 protocol, defined in [14]. 1080 PKCS #7, defined in [15]. 1082 - Remote, client/server authentication 1083 GSS v5, specified in RFC 1508 [16]. 1085 - Certification services 1086 PKIX certification protocol, specified in [17]. 1088 +-----------------------------------------------------------+ 1089 | Security Extension Module | 1090 +--------------------------------------+--------------------+ 1091 | Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 | 1092 | Remote, client/server authentication | GSS v5 | 1093 | Certification services | PKIX certification | 1094 | | protocol | 1095 +--------------------------------------+--------------------+ 1097 5.5.6. Payment Extension Module 1099 This module allows a Broker to perform electronic payment operations 1100 with Customers, Suppliers and other Brokers. Such operations may take 1101 place at any stage during a GAIA transaction, during a Search, 1102 Locate, Order or Deliver Action. 1104 The GAIA Standard does not specify the tariffing or charging model to 1105 be used by a Broker, this is considered to be an internal matter. 1106 However, when a bill has been agreed, payment must take place in a 1107 secure and mutually acceptable manner. The payment procedure 1108 specified in the GAIA Standard makes use of the SET specification. 1110 The Payment Extension Module requires for a Broker to support SET 1111 v1.0 merchant's server and SET certification protocol, specified in 1112 [18]. 1114 +----------------------------------------------------+ 1115 | Payment Extension Module | 1116 +------------------------+---------------------------+ 1117 | Payment | SET v 1.0 : | 1118 | | 1) CA server for banks | 1119 | | 2) Cardholder wallet | 1120 | | 3) Merchant Server | 1121 | | 4) Payment Gateway server | 1122 +------------------------+---------------------------+ 1124 5.5.7. Alerting Extension Module 1126 The Alerting Extension Module specifies the protocols to notify 1127 Customers about changes that can be interesting for them. 1129 This Extension Module requires the support of the following 1130 technologies: 1132 - Internet e-mail, based on SMTP protocol [8], 1133 and mail data formats specified in RFC 822 [9]. 1134 The Broker should be able to generate and send e-mail messages. 1135 - SMS (Short Message Service), specified in [19]. 1137 +-----------------------------------------------------+ 1138 | Alerting Extension Module | 1139 +-----------+-----------------------------------------+ 1140 | Alerting | Internet e-mail [SMTP,RFC822] (sender), | 1141 | | SMS | 1142 +-----------+-----------------------------------------+ 1144 5.5.8. Customer Discovery Extension Module 1146 The Customer Discovery Extension Module allows Z39.50 clients to use 1147 the service of the GAIA Broker. 1149 This Extension Module requires the Broker to support the server part 1150 of the Z39.50 protocol, as defined in [5]. The following subset of 1151 the protocol is required 1153 - Init, Search, and Present services 1154 - GRS-1 record syntax 1156 Z39.50 protocol PDUs should be carried using TCP/IP network 1157 protocols. 1159 +----------------------------------------------------+ 1160 | Discovery Extension Module | 1161 +------------------------+---------------------------+ 1162 | Searching, | Z39.50 (server) | 1163 | Locating | | 1164 +------------------------+---------------------------+ 1166 5.6. Interface Modules 1168 For the purpose of conformance all interfaces between FUMs and FUs, 1169 specified by the GAIA Standard, are grouped into GAIA Interface 1170 Modules. These modules are recommended to be supported by a GAIA 1171 Broker, but they are not mandatory. A Broker can choose a subset of 1172 Interface Modules, which is more important in its area of operation, 1173 and implement interfaces defined in these modules. 1175 A full specification of the Functional Unit interfaces is presented 1176 in the GAIA Standard [1]. 1178 The following table defines Interface Modules and specifies, which 1179 interfaces have to be supported in each of them. 1181 +--------------------+------------------------------------+ 1182 | Interface Module | Interfaces that are required to be | 1183 | | supported in this module | 1184 +--------------------+------------------------------------+ 1185 | Search | Search FU interface | 1186 | Locate | Locate FU interface | 1187 | Order | Order FU interface | 1188 | Discrete Delivery | Discrete Delivery FU interface | 1189 | Stream Delivery | Stream Delivery FU interface | 1190 | Customer | Customer FU interface | 1191 | Alerting | Alerting FU interface | 1192 | Directory Services | Directory Services FU interface | 1193 | Authentication | Authentication FU interface | 1194 | Payment | Payment FU interface | 1195 +--------------------+------------------------------------+ 1197 6. Acknowledgement 1199 We wish to express our gratitude to all members of the GAIA 1200 Consortium for very lively discussion and their valuable direct and 1201 indirect input in the process of design of the GAIA Standard. 1203 7. Security Considerations 1205 Security issues related to the electronic brokerage are discussed in 1206 Sections 2.1.4, 2.3 and 5.4.5. 1208 8. References 1210 [1] GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)", 1211 December 1998, see also . 1213 [2] Object Management Group, "CORBA 2.0 Specification", July 1996, 1214 See . 1216 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Berners-Lee, 1217 T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1218 1997. 1220 [4] Berners-Lee, T., Connolly, D., "Hypertext Markup Language - 1221 2.0", RFC 1866, November 1995. 1223 [5] ANSI/NISO Z39.50-1995 or ISO 23950 "Information Retrieval: 1224 Application Service Definition and Protocol Specification". 1226 [6] ISO 10161:1997 "Information and documentation -- Open Systems 1227 Interconnection -- Interlibrary Loan Application Protocol 1228 Specification". 1230 [7] Postel, J., Reynolds, J.K., "File Transfer Protocol", RFC 959, 1231 October 1985. 1233 [8] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1234 1982. 1236 [9] Crocker, D., "Standard for the format of ARPA Internet text 1237 messages", RFC 822, August 1982. 1239 [10] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 1240 Extensions (MIME) Part One: Format of Internet Message Bodies", 1241 RFC 2045, November 1996. 1243 Freed, N., and N. Borenstein, "Multipurpose Internet Mail 1244 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1245 1996. 1247 Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 1248 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 1249 November 1996. 1251 Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 1252 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 1253 2048, November 1996. 1255 Freed, N., and N. Borenstein, "Multipurpose Internet Mail 1256 Extensions (MIME) Part Five: Conformance Criteria and Examples", 1257 RFC 2049, November 1996. 1259 [11] ISO/IEC IS 13818 "Information technology -- Coding of moving 1260 pictures and associated audio information" 1262 Part 1: Systems 1263 Part 2: Video 1264 Part 3: Audio 1265 Part 4: Conformance testing 1266 Part 5: Software simulation 1268 [12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1269 "RTP: A Transport Protocol for Real-Time Applications", RFC 1270 1889, Audio-Video Transport Working Group, January 1996. 1272 [13] Hoffman, D., Fernando, G., Goyal, V., Civanlar, M., "RTP Payload 1273 Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. 1275 [14] Freier, A., Karlton, P., Kocher, P., "The SSL Protocol - Version 1276 3.0", INTERNET-DRAFT, Transport Layer Security Working Group, 1277 November 1996, 1278 See . 1280 [15] PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, 1281 November 1993. 1283 [16] Linn, J., "Generic Security Service Application Program 1284 Interface", RFC 1508, Geer Zolot Associate, September 1993. 1286 [17] Public-Key Infrastructure (X.509) IETF Working Group, 1287 , July 98. 1289 [18] "SET Secure Electronic Transaction Specification", Version 1.0, 1290 MasterCard and Visa, May 97. 1292 [19] Digital Cellular Telecommunications System (Phase 2+): Technical 1293 Realization of the Short Message Service (SMS) Point-to-Point 1294 (PP) (GSM 3.40). Version 5.2.0. European Telecommunications 1295 Standards Institute. May 1996. 1297 9. Authors' Addresses 1299 Mikhail Blinov 1300 Computer Science Department, University College Dublin, 1301 Belfield, Dublin 4, Ireland 1303 Phone: +353 1-706-2488 1304 Fax: +353 1-269-7262 1305 EMail: mch@net-cs.ucd.ie 1307 Mikhail Bessonov 1308 Computer Science Department, University College Dublin, 1309 Belfield, Dublin 4, Ireland 1311 Phone: +353 1-706-2488 1312 Fax: +353 1-269-7262 1313 EMail: mikeb@net-cs.ucd.ie 1315 Ciaran Clissmann 1316 Computer Science Department, University College Dublin, 1317 Belfield, Dublin 4, Ireland 1319 Phone: +353 1-706-2488 1320 Fax: +353 1-269-7262 1321 EMail: ciaranc@net-cs.ucd.ie 1323 10. Full Copyright Statement 1325 Copyright (C) The Internet Society (1998). All Rights Reserved. 1327 This document and translations of it may be copied and furnished to 1328 others, and derivative works that comment on or otherwise explain it 1329 or assist in its implementation may be prepared, copied, published 1330 and distributed, in whole or in part, without restriction of any 1331 kind, provided that the above copyright notice and this paragraph are 1332 included on all such copies and derivative works. However, this 1333 document itself may not be modified in any way, such as by removing 1334 the copyright notice or references to the Internet Society or other 1335 Internet organizations, except as needed for the purpose of 1336 developing Internet standards in which case the procedures for 1337 copyrights defined in the Internet Standards process must be 1338 followed, or as required to translate it into languages other than 1339 English. 1341 The limited permissions granted above are perpetual and will not be 1342 revoked by the Internet Society or its successors or assigns. 1344 This document and the information contained herein is provided on an 1345 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1346 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1347 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1348 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1349 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1351 INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT