Document communications controller

Abstract

The present invention is a method and apparatus for providing a general-purpose, multifunction, individually addressable, full-bandwidth bi-directional communication device with built-in Authentication, Authorization, and Accounting (AAA) capabilities that connects a home or business user with ATM and other switched broadband digital networks in a convenient, adaptable, extensible manner at reasonable cost. The device supports a Document Services Architecture (DSA) and, in particular, supports agent-based communications (including interaction with an Agent Instance Service) to ensure well-behaved communications and fair allocation of network resources among users. The device can be used in a heterogeneous environment and with different types of networks and protocols. The full-bandwidth bi-directional communication and built-in AAA capabilities of the device distinguish it from other "set-top boxes."

Claims

What is claimed is:

1. A method for controlling communication on a broadband communication system in which communication takes place between an invoking principal that uses an information service and an invoked principal that provides the information service, comprising the steps of:

identifying a first agent for the invoking principal and a second agent for the invoked principal; and

defining a set of transaction methods, accessible by said agents, for establishing a dyad between the invoking principal and the invoked principal, said transaction methods providing communications services to the dyad for generating at both the first agent and the second agent an accounting record for the information service; the accounting records including billing processes and being transmitted by the first agent and the second agent to an accounting service.

2. The method of claim 1, further comprising the step of recording payment required by the first agent for the services received from the second agent.

3. The method of claim 1, wherein the transaction methods provide communications services that include authentication.

4. The method of claim 1, wherein the transaction methods provide communications services that include authorization.

5. A document services architecture facilitating communication over a broadband communication system in which communication takes place between an invoking principal that uses an information service and an invoked principal that provides the information service, comprising:

means for identifying a first agent for the invoking principal and a second agent for the invoked principal; and

means for defining a set of transaction methods, accessible by said agents, for establishing a dyad between the invoking principal and the invoked principal, said transaction methods providing communications services to the dyad for generating at both the first agent and the second agent an accounting record for the information service; the accounting records including billing processes and being transmitted by the first agent and the second agent to an accounting service.

6. The document services architecture of claim 5, wherein the invoked principal is a telephone service.

7. The document services architecture of claim 6, wherein the invoking principal is a user of the telephone service.

Description

This invention relates generally to telecommunications, and more particularly to an apparatus designed to provide a common interface between existing and future telecommunication equipment and a plurality of broadband information distribution networks.

CROSS REFERENCE

The following related application is hereby incorporated by reference for its teachings:

"PRINCIPLED DOCUMENT BANK," Paul V. Grantham et al., application Ser. No. 08/768,452, filed concurrently herewith. (Atty. Docket No. D/95287)

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND AND SUMMARY OF THE INVENTION

The present invention is an apparatus adapted to provide commonality in the interface between a user's telecommunication equipment and a plurality of broadband information distribution networks. The functionality of the present invention further includes an architecture through which a user (or more appropriately a principal) may obtain secure, authorized and billable connections to broadband networks. The invention provides a general-purpose, multifunction, individually addressable, full-bandwidth bi-directional communication device with built-in Authentication, Authorization, and Accounting (AAA) capabilities that connect a home or business user with ATM and other switched broadband digital networks in a convenient, adaptable, extensible manner at reasonable cost. The device supports a Document Services Architecture (DSA) and, in particular, supports agent-based communications (including interaction with an Agent Instance Service) to ensure well-behaved communications and fair allocation of network resources among users. The device can be used in a heterogeneous technical environment and with different kinds of networks and protocols. The full-bandwidth bi-directional communication and built-in AAA capabilities of the device distinguish it from other "set-top boxes."

It will be appreciated by those skilled in the art of telecommunications that in order to further encourage commerce via the national information infrastructure (NII) that the digital exchange of information must be facilitated. However, the goal of unlimited access to digital information or "works" has been unrecognized. This is primarily due to the lack of a mechanism or system by which an owner of a digital work can be assured of compensation for allowing authorized access to the work. This is also due to the sometimes prohibitive cost of systems and interfaces to the NII. Hence, the present invention is directed to a document communications controller that not only provides a low-cost interface to communications networks, but also provides the services necessary to assure that commercial transactions over a broadband network are authenticated, authorized and accountable.

Heretofore, a number of patents and publications have disclosed various aspects of usage rights, architectures and protocols associated with broadband communications, the relevant portions of which may be briefly summarized as follows:

In "Requirement for Authenticated Signaling: contribution T1S1.5/94-118 to Standards Committee T1S," submitted Apr. 11-15, 1994, Bryan Lyles proposed that authenticated signaling be made a part of signaling. The contribution offered two principal reasons: (a) the efficient maintenance of security, particularly in the presence of "security firewalls" as used in many companies and institutions today, and (b) the efficient prevention of fraud.

In "Service Models and Pricing Policies for an Integrated Services Internet," Proceedings of "Public Access to the Internet". Harvard University, 1993, Scott Shenker argues that an efficient integrated services Internet--his use of the term includes B-ISDN ATM service--must employ per-user, quality-of-service sensitive, and usage-based pricing policies. Implementing such policies requires that the network provider have a capability of recording network usage according to the quality of service employed, and assign costs of such usage to individual clients. Specifically, "[t]he network accounting infrastructure must be built into the basic underlying network protocols. These protocols must not only be able to support accounting, but also some degree of authentication, so that charges are not misassigned." This implies a known, defined relationship between the object that is authenticated and that against which accounting data accrues. As described by T. Smith & J. Stidd, in Requirements and Methodology for Authenticated Signaling, ATM Forum/94-1213 (SA&A Sub Working Group), Nov. 10, 1994, hereby incorporated by reference for its teachings, commerce over a broadband network requires, in addition to Authentication and Accounting. Authorization. A service provider may be satisfied that the requesting party is genuine and that an account for accrual of charges is available, but the provider may not wish to grant the request for any number of reasons, including credit standing or age. Further, Authorization may be a service that the provider wishes to "outsource" to another provider, such as a credit card organization. All of these services depend critically on Authentication and on the identification of the authenticated object with the authorized object and the accounting data accrual object. Efficiency and commerce, in turn, depend critically on the services being at least implementable in broadband protocols. If authentication is not done at call setup time, it must be done "out of band". This would be at least more expensive and time consuming, if not dependent itself on some form of authenticated signaling.

Broadband services inevitably raise issues of privacy and responsibility. Preserving the privacy of the individual within a family or other collocated group, and exercising parental norms, in the absence of user-based setup, would require individual "addresses" or some overhead-laden out-of-band scheme. Implementation of broadband telephony, especially when described as the "information superhighway" and the like, poses many challenges. It is unreasonable to suppose that the public market is going to wait for all of the necessary standards to be in place before charging ahead with what is possible, even if the approaches to the problems those standards pose aren't well treated or even posed. Establishing authenticatable, user-based communication as a basis for efficient commerce, not to mention efficient network provisioning, is a problem that must be resolved to enable electronic commerce.

At the present time, Internet security is generally handled by "security firewalls", as described by Lyles. These firewalls must examine all of the Internet packet headers passing through the firewall to verify that communication is occurring only between authorized host systems. While this security filter will work over any network, including B-ISDN, it will cause severe performance degradation of a high-speed connection, since the router software implementing the firewall may be unable to process the data fast enough to prevent slowdown. Some method is needed to inform the firewall of the source and destination systems involved in a B-ISDN connection so that the data can be passed around the firewall, if the connection is authorized, in order to avoid terminating one end of the connection at the firewall.

The present invention is directed to aspects of computer network authentication that depends on verifying the identity of a user by requiring proof of knowledge of the value of secret data. This secret data, called the "key", is unique for every user, and is used whenever the user must prove identity. A trivial version of this is the password that a user must enter in order to log in to most computer systems. A much more sophisticated and secure method is available in the federal government's Digital Signature Standard (DSS), FIPS 186, Digital Signature Specification, NIST, 1993. DSS is based on public key cryptography, which uses two separate keys, one for encryption and the other for decryption. Using the secret encryption key, the user encrypts a block of several data items to form a "digital signature". The data items and the signature are then examined by whoever must verify the authenticity of the user's identity. The digital signature is decrypted with the user's publicly known decryption key. (For example, the public key may be stored in a user directory.) If the decrypted signature forms the same data items that were also available in clear text, then the user must have known the secret encryption key, and hence is authentic. (The secret and public keys are generated in pairs, and one cannot be derived from the other.) Given the ease of administration of an authentication system based on DSS, and the fact that DSS is exportable without restriction under federal law, it is proposed here as the algorithm used in the authentication. However, the rest of this proposal would work with any digital signature or password scheme; it does not depend fundamentally on DSS.

U.S. Pat. No. 5,305,311 to Lyles, issued Apr. 19, 1994, discloses a copy network providing multicast capabilities in a broadband ISDN fast packet switch.

U.S. Pat. No. 4,761,780 to Bingham et al., issued Aug. 2, 1988, teaches an enhanced efficiency Batcher-Banyan packet switch.

In "Large Packet Switch and Contention Resolution Device," XIII International Switching Symposium--Poster Session, Vol. III, Paper No. 14, pp. 77-83 (May-June 1989), A. Cisneros teaches a contention resolution mechanism in a packet switch. The mechanism allows arbitration over a large number of input lines at a high speed.

In "All Aboard the SST", Computer Letter (Technologic Partners), Vol. 9 No. 32, (Sep. 27, 1993), pp. 1-7, describes a need for a smart set-top (SST) box positioned at the hub of a system to request services, information and programming from an upstream network, while using a VCR and TV as peripherals in a mode similar to a personal computer or workstation.

To further understand the advantages of the present invention, it is best to provide some background associated with existing or contemplated technology. First, the set-top box, where the model is that of an "information diode." Broadband transmission runs from the service provider (the "head end") to the consumer, with very low bandwidth transmission in the reverse direction. The head end has a powerful server computer, whereas the consumer has a relatively dumb box acting as the document communications controller (DCC). There is no built-in AAA; instead, authentication and authorization is per box, not per user, and accounting is handled by metering performed at the head end. The envisioned range of applications focuses on home entertainment and information services.

CommerceNet, Netscape 2.0--This model contemplates two-way communication between sellers and buyers of goods and services. Bandwidth is generally somewhat limited (MBone is a possible exception?). At either end of the communication can be a personal computer, a workstation, or a local-area network. Authentication and authorization is layered on top of the basic Internet protocol, rather than being built in from the ground up. There is no built-in accounting function. The envisioned range of applications focuses on business conducted over the Internet, which includes the provision of goods and services to end-use consumers and also interactions between businesses, including a lack of service level management businesses that act as intermediaries or brokers.

In accordance with the present invention, there is provided a document communications control device, comprising:

a processor;

a first hardware interface for establishing an interconnection between the document communications control device and a broadband network;

a customer premises equipment interface for interconnecting the document communications control device with customer premises equipment; and

memory for storing code executable on said processor

said code including an operating system and communications protocols to implement a plurality of document service functions including at least one of authorization, authentication and accounting.

In accordance with another aspect of the present invention, there is provided a communications system, including:

a first document communications controller comprising a processor, a first hardware interface for establishing an interconnection between the document communications control device and a broadband network, a customer premises equipment interface for interconnecting the document communications control device with customer premises equipment, and memory for storing code executable on said processor, said code including an operating system and communications protocols to implement a plurality of document service functions including authorization, authentication and accounting;

a second document communications controller also comprising a processor, a first hardware interface for establishing an interconnection between the document communications control device and a broadband network, a customer premises equipment interface for interconnecting the document communications control device with customer premises equipment, and memory for storing code executable on said processor, said code including an operating system and communications protocols to implement a plurality of document service functions including authorization, authentication and accounting; and

a broadband communications network interconnecting said first and said second document communications controllers.

One aspect of the invention deals with a basic problem in broadband telecommunications (e.g., an asynchronous transfer mode (ATM) network)--that of providing a common interface for various pieces of telecommunications equipment that presently exist in a home, office or similar location. In particular, it is necessary to provide a low-cost document communications controller (i.e., a document communications controller) that may be employed as either a set-top or point of service entry unit.

This aspect is further based on the discovery of an architecture that alleviates this problem. The architecture includes a document communications controller (DCC) that not only serves as the physical interface with the ATM service, but also provides a software interface to a plurality of software modules. The combination of the document communications controller and its associated software and communications capabilities is one aspect of a communications system infrastructure that may be employed to provide secure, authorized and billable access to the ATM networks.

In a collaborative workgroup environment, the DCC provides a cost effective way of networking desktops, including video, sound, document transfer and telephone connection switching. The DCC can also be employed to connect existing local area network environments to an ATM backbone serving entire buildings. For home communications, the DCC provides a low cost method of delivering on-demand video, telephone and print distribution to the home over a single connection. It is submitted that the DCC will support telecommuting by enabling the establishment of direct video, audio and document interchange with colleagues--at a level of quality superior to ISDN environments. Moreover, the present invention enables multicasting, and the document communications capabilities of the DCC allow a consumer to exploit the most cost effective communication mode.

The system broadly described above is advantageous because it is both efficient and inexpensive compared to other approaches, while making it unnecessary to have a plurality of service access devices (e.g., one for each telecommunication device). The plurality of service access devices are thereby replaced by, or interconnect to, a centrally managed port. Moreover, the proposed document communications controller is flexible and can be adapted to provide access via any of a number of broadband communication networks. The present invention can be used to provide additional communications services to the consumer via expansion of consumer-owned services or via third party services. The techniques of the invention are advantageous because they provide a range of communication alternatives, each of which is useful in appropriate situations. A wide variety of operations can be implemented using these techniques, including the implementation of accounting, authorization and authentication for transactions accomplished via the communications networks. As a result of the invention, it is believed that consumers will be provided with a convenient, cost-competitive interface to broadband communication networks .

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a general representation of the Document Services Architecture (DSA) for broadband communication services in accordance with an aspect of the present invention;

FIG. 2 is a more detailed view of the various elements that comprise a principal in the DSA of FIG. 1;

FIG. 3 is a detailed pictorial representation of the elements that form a communication dyad as depicted in FIG. 1;

FIG. 4 is a diagram depicting the hierarchical model of the levels of the DSA;

FIG. 5 is a is a more detailed diagram of the software architecture in the DSA code level of the present invention;

FIG. 6 is a data flow diagram illustrating the authentication process carried out in accordance with an aspect of the present invention;

FIG. 7 is a data flow diagram illustrating the establishment of a dyad;

FIG. 8 is a data flow diagram representing communications between an accounting service and a billing service in accordance with an accounting aspect of the present invention;

FIG. 9 is an exemplary broadband network environment in which the present invention finds particular use;

FIG. 10 is a data flow diagram illustrating the document communications controller in one network interface embodiment;

FIG. 11 is a detailed view of the physical interconnections accomplished by the document communications controller;

FIG. 12 is a schematic illustration of an exemplary hardware embodiment for the document communications controller;

FIG. 13 is a block diagram illustrating the various elements of the hardware embodiment of FIG. 12;

FIG. 14 is a block diagram of the ATM subsystem in accordance with one embodiment of the present invention;

FIG. 15 is a hardware block diagram illustrating the various compenents of an alternative embodiment of the document communications controller;

FIG. 16 is a representative illustration of the physical layout of the hardware components depicted in FIGS. 12-14;

FIG. 17 is a pictorial representation of an overview of the ATM software architecture with layer labels corresponding to the OSI Reference Model;

FIG. 18 is a detailed view of the software architecture illustrating the interrelationships between various aspects of the User Plane depicted in FIG. 17;

FIG. 19 is a detailed view of the software architecture illustrating the interrelationships between various aspects of the Control Plane depicted in FIG. 17;

FIG. 20 is an exemplary illustration of an embodiment of the User and Control planes depicted in FIGS. 18 and 19; and

FIG. 21 is a detailed view of the software architecture illustrating the interrelationships between various aspects of the ATM Management Plane depicted in FIG. 17.

The present invention will be described in connection with a preferred embodiment, however, it will be understood that there is no intent to limit the invention to the embodiment described. On the contrary, the intent is to cover all alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.

DESCRIPTION OF THE PREFERRED EMBODIMENT

For a general understanding of the present invention, reference is made to the drawings. In the drawings, like reference numerals have been used throughout to designate identical elements. In describing the present invention, the following term(s) have been used in the description.

The term "data" refers herein to physical signals that indicate or include information. When an item of data can indicate one of a number of possible alternatives, the item of data has one of a number of "values." For example, a binary item of data, also referred to as a "bit," has one of two values, interchangeably referred to as "1" and "0" or "ON" and "OFF" or "high" and "low." A bit is an "inverse" of another bit if the two bits have different values. An N-bit item of data has one of 2N values. A "multi-bit" item of data is an item of data that includes more than one bit. The term "data" includes data existing in any physical form, and includes data that are transitory or are being stored or transmitted. For example, data could exist as electromagnetic or other transmitted signals or as signals stored in electronic, magnetic, or other form.

"Circuitry" or a "circuit" is any physical arrangement of matter that can respond to a first signal at one location or time by providing a second signal at another location or time. Circuitry "stores" a first signal when it receives the first signal at one time and, in response, provides substantially the same signal at another time. Circuitry "transfers" a first signal when it receives the first signal at a first location and, in response, provides substantially the same signal at a second location.

A "data storage medium" or "storage medium" is a physical medium that can store data. Examples of data storage media include magnetic media such as diskettes, floppy disks, and tape; optical media such as laser disks and CD-ROMs; and semiconductor media such as semiconductor ROMs and RAMs. As used herein, "storage medium" covers one or more distinct units of a medium that together store a body of data. For example, a set of floppy disks storing a single body of data would together be a storage medium. A "storage medium access device" is a device that includes circuitry that can access data on a data storage medium. Examples include drives for reading magnetic and optical data storage media.

"Memory circuitry" or "memory" is any circuitry that can store data, and may include local and remote memory and input/output devices. Examples include semiconductor ROMs, RAMs, and storage medium access devices with data storage media that they can access. A "memory cell" is memory circuitry that can store a single unit of data, such as a bit or other n-ary digit or an analog value.

A "data transmission medium" or "transmission medium" or "communications medium" is a physical medium that transmits or transfers data from one location to another.

A "data processing system" is a physical system that processes data. A "data processor" or "processor" is any component or system that can process data, and may include one or more central processing units or other processing components. A processor performs an operation or a function "automatically" when it performs the operation or function independent of concurrent human control. A "processing unit" is a processor that is a component within another processor.

The terms "coprocessor" and "host processor" are complementary terms. A "host processor" is capable of operating independently but it can also be connected to a "coprocessor" so that the host processor and the coprocessor operate in an interdependent manner.

A signal "indicates" or "selects" one of a set of alternatives if the signal causes the indicated one of the set of alternatives to occur. For example, a signal can indicate one bit set in a sequence of bit sets to be used in an operation, in which case the signal causes the indicated bit set to be used in the operation.

Any two components are "connected" when there is a combination of circuitry that can transfer signals from one of the components to the other. For example, two components are "connected" by any combination of connections between them that permits transfer of signals from one of the components to the other.

A processor "accesses" an item of data in memory by any operation that retrieves or modifies the item, such as by reading or writing a location in memory that includes the item. A processor can be "connected for accessing" an item of data by any combination of connections with local or remote memory or input/output devices that permits the processor to access the item.

A "data unit" or "unit of data" is an item of data that a processor can access or otherwise operate on as a unit. For example, an eight-bit byte is a data unit in many data processing systems. A "block" of items of data is a number of items of data that form a sequence.

A processor or other component of circuitry "operates on" an item of data by performing an operation that includes obtaining a resulting item of data that depends on the item of data operated on. For example, the resulting item of data could result from an operation that accesses the item of data operated on or from a logic or arithmetic operation on the item of data operated on.

An "operand" is an item of data on which an operation is performed. An operation is performed "using an operand" when the operation is performed on the operand. An "arithmetic operation" is an operation that obtains a numerical result that depends on the value of an operand. Addition, subtraction, multiplication, and division are examples of arithmetic operations.

A "logic operation" is an operation that obtains one bit using each bit of an operand independent of values of other bits of the operand. NOT is an example of a logic operation that uses one operand. OR, AND, and XOR are examples that use two or more operands. Some arithmetic operations can be efficiently implemented using logic operations, but others include carrying, borrowing, or shifting, making such implementation difficult.

A "binary outcome operation" is an operation that obtains a binary result that depends on the numerical value of an operand. >, <, and = are examples of binary outcome operations. A binary outcome operation "compares" a component data item with another value when it applies one or more of the operators >, <, and = to determine how the value of the component and the other value are related. A "flag bit" is a bit indicating a result of a binary outcome operation.

A processor or other circuitry performs an operation "in parallel" on an operand that includes plural bits when a result is obtained for all of the bits at approximately the same time. The amount of time required may, for example, be a single clock cycle of a processor. A "composite operand" is an operand that includes two or more data items, referred to as "component data items" or "components." A logic operation is performed "in parallel" using a multi-bit operand when the logic operation is performed independently on each bit of the operand. NOT is a logic operation that can be performed in parallel using one multi-bit operand. AND, OR, and XOR are logic operations that can be performed in parallel using two or more multi-bit operands.

A bit in an operand of an operation performed in parallel is "aligned" with a bit in a result of the operation if the operation uses the bit in the operand to obtain the bit in the result. Similarly, a bit in a first operand is "aligned" with a bit in a second operand if the operation uses the two bits to obtain a bit in the result. A first multi-bit data item is "aligned" with a second multi-bit data item if each bit of the first data item is aligned with a bit of the second data item.

A logic operation "merges" two composite operands that include plural component data items aligned in pairs if the result of the operation includes, for each pair, one component that has the same value as one of the components in the pair.

A logic operation "selects" bits or data items from an operand if, in the result, bits or data items aligned with the selected bits or data items have the same value as the selected bits or data items while all other bits in the result have a uniform value.

A "mask operand" or "mask" is an operand on which an operation can be performed together with another operand to select bits or data items in the other operand.

A processor or other circuitry performing an arithmetic operation on a composite operand may produce an "inter-component signal." An inter-component signal is a signal like a carry signal, a borrow signal, or a shifted bit that may cause an operation on one component to affect results obtained for another component.

A binary number can be represented as a sum of powers of two. Each bit in the binary number indicates presence or absence of a particular power of two in the sum. Therefore, the "most significant bit" or "MSB" of a binary number is the bit that indicates presence or absence of the largest power of two and the "least significant bit" or "LSB" is the bit that indicates presence or absence of the smallest power of two. Conventionally, the bits of a binary number are ordered in sequence from MSB to LSB or vice versa. As used herein, "left" and "leftward" arbitrarily refer to a direction toward an MSB in sequence while "right" and "rightward" arbitrarily refer to a direction toward an LSB in sequence. The "most significant bit position" of a subarray of processing positions operating on a binary number is a position operating on the MSB of the binary number. The "least significant bit position" of a subarray of processing positions operating on a binary number is a position operating on the LSB of the binary number.

A processor or other component of circuitry "uses" an item of data in performing an operation when the result of the operation depends on the value of the item. For example, the operation could perform a logic or arithmetic operation on the item or could use the item to access another item of data.

An "address" is an item of data that can be used to address a memory cell within memory circuitry that includes plural memory cells.

Stored data can be "accessed using" or "accessible using" other data if the memory containing the stored data responds to the other data or to data that depends on the other data by permitting access to the stored data. For example, the other data may be an address, an offset used to produce an address, or a content-addressable value stored with the stored data.

An "instruction" is an item of data that a processor can use to determine its own operation. A processor "executes" a set of instructions when it uses the instructions to determine its operations. Execution of instructions "causes" a processor to perform an operation when the processor performs the operation in the process of executing the instructions. A signal "requests" or "is a request for" an event or state when the signal can cause occurrence of the event or state. To "obtain" or "produce" an item of data is to perform any combination of operations that begins without the item of data and that results in the item of data. An item of data can be "obtained" or "produced" by any operations that result in the item of data. An item of data can be "obtained from" or "produced from" other items of data by operations that obtain or produce the item of data using the other items of data.

An "amount of data" in an item of data can be measured by counting the number of units of data of a specific size in the item of data. The amount of data in a binary item of data can be measured, for example, by counting the number of bits in the item. An item of data defines an image "with an amount of data" when the part of the item of data that defines the image includes the amount of data.

An item of data "identifies" or "is an identifier of" one of a set of identifiable items if the item of data is one of a set of items of data, each of which can be mapped to at most one of the identifiable items.

An operation "encodes" items of data when performing the operation on the items of data produces different items of data from which the encoded data items can subsequently be recovered. The operation that recovers the encoded data items is "decoding."

A first item of data "indicates" a second item of data when the second item of data can be obtained from the first item of data. The second item of data can be accessible using the first item of data. Or the second item of data can be obtained by decoding the first item of data. Or the first item of data can be an identifier of the second item of data. For example, an item of data may indicate a set of instructions a processor can execute or it may indicate an address.

"Code" of "software code" means data indicating instructions, but in a form that a processor can execute or in a form that can be processed (e.g., compiled, linked, assembled) to produce a form that a processor can execute.

An item of data "indicates" a thing, an event, or a characteristic when the item has a value that depends on the existence or occurrence of the thing, event, or characteristic or on a measure of the thing, event, or characteristic.

An item of data "includes" information indicating a thing, an event, or a characteristic if data indicating the thing, event, or characteristic can be obtained by operating on the item of data. Conversely, an item of information that indicates a thing, an event, or a characteristic can be said to "include" an item of data if data indicating the thing, event, or characteristic can be obtained by operating on the item of data.

An operation or event "transfers" an item of data from a first component to a second if the result of the operation or event is that an item of data in the second component is the same as an item of data that was in the first component prior to the operation or event. The first component "provides" the data, and the second component "receives" or "obtains" the data.

An "Account Record" is a data set comprising an account-header, extension-vector(s) and trailer-record containing a common conversion identifier (CID) and globally unique identifier for a transaction method tree instance (GUTMID). An "Account-Base" is an unordered set of zero or more account records. An "Account-Entry" is a set of account records containing a common, unique GUTMID. (i.e., generated by a single transaction method tree instance), and an "Account-Journal" is a collection of account records generated by a given principal.

An "Extension-Vector" is a sub-set of an account record that consists of a principal defined collection of {LENGTH.vertline.TYPE.vertline.VALUE} attributes.

As noted above, "GUTMID" is an acronym for a globally unique identifier for a transaction method tree instance. The GUTMID is produced by a root transaction method (the transaction method instantiated by BSOM, not by receipt of a C-Begin request), and is propagated down the transaction tree constructed by subsequent invocations. The GUTMID may be used to correlate all arcs and nodes involved in a distributed, nested set of transaction method instances.

Document Services Architecture (DSA) Overview

Referring to FIG. 1, shown therein is a general representation of the Document Services Architecture (DSA). DSA is an architecture by which communication takes place between at least two principals 30. As illustrated in the diagram of FIG. 1, a principal may represent, among other things, people, services and documents. Principals, using agents 32 as intermediaries, communicate via dyads 34. A "principal" is a named set of transaction methods (TM). During the existence of any conversation between principals, there are four items of information available: (i) the name of the invoking principal; (ii) the name of the invoked principal; (iii) the name of the executing transaction method within the invoking principal; and (iv) the name of the invoked transaction within the invoked principal. "Dyads" are abstractions of a communications session representing, for example, authentication of the principals at both ends. Dyads "contain" the active conversations between two principals and, using a communication infrastructure 36, "carry" data between the two principals. As illustrated, there is precisely one agent for each active principal. The agent 32 implements the DSA communications. To provide required communication services, the agent also implements/possesses agent methods.

The DSA does not distinguish the agent's methods from the principal's transaction methods. In other words, the same object class preferably represents both sets of transaction methods. However, the DSA architecture uses different communication abstractions for the two types of transaction methods where the semantics are the same. For example, principal transaction methods may use the syntax represented by communication verbs beginning with "dyad.sub.-- ", for example

dyad.sub.-- begin represents the verb, c.sub.-- begin. Infrastructure transaction methods, or "connection abstractions," begin with the text, "connection.sub.-- ", for example

connection.sub.-- begin

representing c.sub.-- begin. The semantics for both uses of the communication verbs are the same. So the agent provides the DSA communication application program interface (API) to principals' transaction methods. The communication services, or access to infrastructure services is provided via the agent API, but implemented in agent transaction methods. There are agent transaction methods for each of the infrastructure services (Agent Instance Service, Authentication, Authorization and Accounting) as represented by Table A.

                  TABLE A
    ______________________________________
    Agent Instance Service (AIS)
                       lookup-by-name
                       lookup-by-address
                       find-AIS
                       register-principal
                       un-register-principal
    Authentication Service
                       authenticate-principal
    Authorization Service
                       get-authorization-ticket
                       get-capability
                       validate-authorization-ticket
                       get-access-class
    Accounting Service account-open-record
                       account-close-record
                       account-append-record
                       account-flush-record
    ______________________________________

                  TABLE C
    ______________________________________
    Account-Record
              Extension-Header
                          Extension-Vector
                                      Trailer-Record
    ______________________________________
    Length    CID         Length      CID
    Type      GUTMID      Type        Gutmid
    P-i                   Value       Time-Stamp
    TM-1                  Billable?   Status
    P-2
    TM-2
    CID
    GUTMID
    Billable?
    Time-Stamp
    ______________________________________

                                      APPENDIX
    __________________________________________________________________________
    account-do.re
    #.parallel.
    Copyright (C) 1995 Xerox Corporation. All Rights Reserved. Copyright
    protection claimed includes all forms and matters of copyrightable
    material and information now allowed by statutory or judicial law or
    hereinafter granted, including without limitation, material generated
    from the software programs which are displayed on the screen such as
    icons, screen display looks, etc.
    .parallel.#
     !! in-package("RU")
    !! in-grammar('user)
    constant *account-length*: integer = 555
    constant *account-type*: integer = 666
    var ACCOUNTTNG-SERVICE: object-class subtype-of infrastructure
     var Accounting-Service-Name: map(accounting-service, symbol)
    = {.parallel.}
     var Acct-Data-Base: map(accounting-service, set(account-base))
     computed-using Acct-Data-Base(@@) = {}
    var ACCOUNT-BASE: object-class subtype-of accounting-service
     var Database-Manager-Name: map(account-base, set(symbol))
     computed-using database-manager-name(@@) = {}
     var account-base-records: map(account-base, set(account-record))
     computed-using account-base-records(@@) = {}
    #.parallel.
    var ACCOUNT-BUFFER: object-class subtype-of conversation
     var account-buffer-records: map(account-buffer, set(account-record))
     computed-using account-buffer-records(@@) = {}
     var account-buffer-id: map(account-buffer, integer) = {.parallel.}
     var conversation-sending-receiving: map(conversation, account-buffer) =
    {.parallel.}
    .parallel.#
    var ACCOUNTING-MIB: object-class subtype-of accounting-service
     var MIB-Module-Identity: map(accounting-MIB, symbol) = {.parallel.}
     var MIB-Module-Description: map(accounting-MIB, string) = {.parallel.}
    var ACCOUNT-RECORD: object-class subtype-of conversation
     var account-header-value: map(account-record, account-header)
    = {.parallel.}
     var extension-vector-value: map(account-record, set(extension-vector))
     computed-using extension-vector-vaiue(@@) = {}
     var trailer-record-value: map(account-record, trailer-record)
    = {.parallel.}
    var ACCOUNT-HEADER: object-class subtype-of account-record
     var account-length: map(account-header, integer) = {.parallel.}
     var account-type: map(account-header, integer) = {.parallel.}
     var P-1: map(account-header, dsa-narue) = {.parallel.}
     var TM-1: map(account-header, dsa-name) = {.parallel.}
     var P-2: map(account-header, dsa-name) = {.parallel.}
     var TM-2: map(account-header, dsa-name) = {.parallel.}
     var cid: map(account-header, integer) = {.parallel.}
     var account-GUTMID: map(account-header, gutmid) = {.parallel.}
     var account-billable?: map(account-header, boolean) = {.parallel.}
     var account-time-stamp: map(account-header, dsa-time) = {.parallel.}
    var EXTENSION-HEADER: object-class subtype-of account-record
     var ext-length: map(extension-header, integer) = {.parallel.}
     var ext-type: map(extension-header, integer) = {.parallel.}
     var ext-gutmaid: map(extension-header, gutmid) = {.parallel.}
     var ext-cid: map(extension-header, integer) = {.parallel.}
    var EXTENSION-VECTOR: object-class subtype-of account-record
     var acct-value: map(extension-vector, symbol) = {.parallel.}
     var acct-value-length: map(extension-vector, integer) = {.parallel.}
     var acct-value-type: map(extension-vector, integer) = {.parallel.}
     var extension-billable?: map(extension-vector, boolean) = {.parallel.}
    var TRAILER-RECORD: object-class subtype-of account-record
     var trailer-Time-Stamp: map(trailer-record, dsa-time) = {.parallel.}
     var status: map(trailer-record, integer) = {.parallel.}
     var trailer-type: map(trailer-record, integer) = {.parallel.}
    var conversation-account-record: map(conversation, account-record) =
    {.parallel.}
    var Accounting-Service-Methods: set(symbol) = {'account-open-record-tm,
                'account-close-record-tm,
                'account-append-record-tm,
                'account-flush-record-tm,
                'account-forward-tm,
                'account-accept-tm,
                'account-retrieve-tm,
                'account-delete-on-attrs-tm,
                'account-extract-on-attrs-tm }
    var ACCOUNTING-VERB: object-class subtype-of DSA-verb
    var ACCOUNTING-INTERFACE: map(dsa-context, set(accounting-verb))
             computed-using accounting-interface(@@) = {}
    var ACCOUNT-OPEN-RECORD: objectclass subtype-of accounting-verb
     var AORconversation: map(account-open-record, conversation)
    = {.parallel.}
     var AOR-billable?: map(account-open4ecord, boolean) = {.parallel.}
     var AOR-reason-code: map(account-open-record, reason-code)
    = {.parallel.}
    var ACCOUNT-CLOSE-RECORD: objectclass subtype-of accounting-verb
     var ACR-conversation: map(account-close-record, conversation)
    = {.parallel.}
     var ACR-billable?: map(account-close-record, boolean) = {.parallel.}
     var flush?: map(account-close-record, boolean) = {.parallel.}
     var ACR-reason-code: map(account-close-record, reason-code)
    = {.parallel.}
    var ACCOUNT-APPEND-RECORD. object-class subtype-of accounting-verb
     var AARconversanon: map(account-append4ecord, conversafion)
    = {.parallel.}
     var extension.sub.-- vector: map(account-append-record, symbol) =
    {.parallel.}
     var AAR-reason-code: map(account-append-record, reason-code)
    = {.parallel.}
    var ACCOUNT-FLUSH-RECORD: object-class subtype-of accounting-verb
     var AFR-conversation: map(account-flush-record, conversation)
    = {.parallel.}
     var AFR-reason-code: map(account-flush-record, reason-code)
    = {.parallel.}
    var ACCOUNT-FORWARD: object-class subtype-of accounting-verb
     var AF-acct-data-base: map(account-forward, set(account-base))
             computed-using af-acct-data-base(@@) = {}
     var acct-record-p.sub.-- 1: map(account-forward, principal)
    = {.parallel.}
     var to-account-service: map(account-forward, accounting-service) =
    {.parallel.}
     var AF-reason-code: map(account-forward, reason-code) = {.parallel.}
     var result: map(account-forward, string) = {.parallel.}
    var ACCOUNT-RETRIEVE: object-class subtype-of accounting-verb
     var ar-acct-data-base: map(account-retrieve, set(account-base))
             computed-using ar-acct-data-base(@@) = {}
     var sending-p.sub.-- 1: map(account-retrieve, principal) = {.parallel.}
     var ar-reason-code: map(account-retrieve, reason-code) = {.parallel.}
    var ACCT-DELETE-ON-ATTRIBUTES: object-class subtype-of accounting-verb
     var adoa-acct-data-base: map(acct-delete-on-attributes,
    set(account-base))
             computed-using adoa-acct-data-base(@@) = {}
     var adoa-reason-code: map(acct-delete-on-attributes, reason-code) = {}
     var adoa-account-record: map(acct-delete-on-attributes, account-record)
    = {.parallel.}
     var adoa-extension-vector: map(acct-delete-on-attributes,
    set(extension-vector))
             computed-using adoa-extension-vector(@@) = {}
     var adoa-keys: map(acct-delete-on-attributes, seq(symbol))
             computed-using adoa-keys(@@) = []
    var ACCt-EXTRACT-ON-ATTRIBUTES: objectclass subtype-of accounting-verb
     var aeoa-acct-data-base: map(acct-extract-on-attributes,
    set(account-base))
             computed-using aeoa-acct-data-base(@@) = {}
    var aeoa-account-record: map(acct-extract-on-attributes, account-record)
    = {.parallel.}
     var aeoa-extension-vector: map(acct-extract-on-attributes,
    set(extension-vector))
             computed-using aeoa-extension-vector(@@) = {}
     var aeoa-keys: map(acct-extract-on-attributes, seq(symbol))
             computed-using aeoa-keys(@@) = []
     var aeoa-reason-code: map(acct-extract-on-attributes, reason-code) =
    {.parallel.}
    form DECLARE-ACCOUNTING-TREE-ATTRIBUTES
     define-tree-attributes('accounting-service, {'accounting-service-name,
             'acct-data-base));
     define-tree-attributes('account-base, {'database-manager-name,
             'account-base-records });
    % define-tree-attributes('account-buffer, {'account-buffer-records,
    %        account-buffer-id});
     define-tree-attributes('accounting-mib, {'mib-module-identity,
             'mib-module-description});
     define-tree-attributes('account-record, {'account-header-value,
             'extension-vector-value,
             'trailer-record-value});
     define-tree-attributes('account-header, {'account-length,
             'account-type,
             'tm-1,
             'tm-2,
             'cid,
             'account-billable?,
             'account-time-stamp,
             'account-gutmid));
     define-tree-attributes('extension-header, {'ext-length,
             'ext-type,
             'ext-gutmid,
             'ext-cid });
     define-tree-attributes('extension-vector, {'acct-value,
             acct-valuelength,
             acct-value-type,
    'extension-billable?});
     define-tree-attributes('trailer-record,
             'trailer-time-stamp,
             'status,
    'trailer-type});
     define-tree-attributes('account-open-record, {'aor-conversation,
             'aor-billable?,
             'aor-reason-code});
     define-tree-attributes('account-close-record, {'acr-conversation,
             'acr-billable?,
             'flush?,
             'acr-reason-code});
     define-tree-attributes('account-append-record, {'aar-conversation,
             'extension.sub.-- vector,
             'aar-reason-code});
     define-tree-attributes('account-flush-record, {'afr-conversation,
             'afr-reason-code});
     define-tree-attributes('account-forward, {'af-acct-data-base,
             'acct-record-p.sub.-- 1,
             'to-account-service,
             'af-reason-code, 'result});
     define-tree-attributes('account-retrieve, {'ar-acct-data-base,
             'sending-p.sub.-- 1,
             'ar-reason-code});
     define-tree-attributes('acct-delete-on-attributes, {'adoa-acct-data-base,
             'adoa-reason-code,
             'adoa-account-record,
             'adoa-extension-vector,
             'adoa-keys });
     define-tree-attributes('acct-extract-on-attributes, {'aeoa-acct-data-base
             'aeoa-reason-code,
             'aeoa-account-record,
             'aeoa-extension-vector,
             'aeoa-keys})
    ais-dom.re
    #.parallel.
    Copyright (C) 1995 Xerox Corporation. All Rights Reserved. Copyright
    protection claimed includes all forms and matters of copyrightable
    material and information now allowed by statutory or judicial law or
    hereinafter granted, including without limitation, material generated
    from the software programs which are displayed on the screen such as
    icons, screen display looks, etc.
    .parallel.#
    !! in-package("RU")
    !! in-grammar('user)
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    %%%%%%%%%%%%%%%%%%%%%%%
    % ais#domain-model.re
                        %
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    %%%%%%%%%%%%%%%%%%%%%%%
    % Agent Instance Service Object Classes
    var AGENT-INSTANCE-SERVICE: object-class subtype-of infrastructure
     var AIS-NAME: map(agent-instance-service, dsa-name) = {.parallel.}
    var AIS-PROBABILITY-VECTOR: object-class subtype-of agent-instance-service
     var AIS-Vector-Depth: map(ais-probability-vector, integer)
    = {.parallel.}
    var AIS-Vector-Width: map(ais-probability-vector, integer)
    = {.parallel.}
    var Ais-Vector-Filters: map(ais-probabi1ity-vector, set(bloom-filter))
             computed-using ais-vector-filters(@@) = {}
    var BLOOM-FILTER: object-class subtype-of ais-probability-vector
    var BOBS-BLOOM-FILTER: map(bloom-filter, symbol) = {.parallel.}
    var AIS-ENTRY: object-class subtype-of agent-instance-service
    %Following because net-address was defined for convenience, not function
    var REAL-NET-ADDRESS: object-class subtype-of address-family
     var BOBS-REAL-ADDRESS: map(real-net-address, symbol) = {.parallel.}
     var Active-Principal-Name: map(ais-entry, principal) = {.parallel.}
     var Active-Address-Families:
             map(ais-entry, set(address-family))
             computed-using active-address-families(@@) = {}
     var Active-Addresses: map(ais-entry, set(real-net-address))
             computed-using active-addresses(@@) = {}
    var AIS-Active-Agent-List: map(agent-instance-service, set(ais-entry))
             computed-using ais-active-agent-list(@@) = {}
    var Local-Probability: map(agent-instance-service,
             ais-probability-vector) = {.parallel.}



    var AIS-PEER: object-class subtype-of agent-instance-service
    var AIS-Peer-Instance: map(ais-peer, set(agent-instance-service))
             computed-using ais-peer-instance(@@) = {}
    var Peer-Probability: map(ais-peer, ais-probability-vector) = {.parallel.}
    var Agent-Instance-Service-Verbs:
    set(symbol) = {'ais-active,
             'ais-activate,
              'ais-inactive,
              'ais-deactivate,
              'ais-add-address,
              'ais-cut-address,
              'ais-resolve-name,
              'ais-set-vector-attributes,
              'ais-get-vector-attributes,
              'ais-set-vector,
              'ais-get-vector,
              'ais-peer-state)
    var AIS-VERB: object-class subtype-of DSA-verb
    var AIS-ACTIVE: object-class subtype-of ais-verb
    %Supplied:
     var ACT-Pname: map(ais-active, DSA-name) = {.parallel.}
     var ACT-AFamily: map(ais-active, address-family) = {.parallel.}
    var ACT-Address: map(ais active, real-net-address) = {.parallel.}
    %Returned:
    var ACT-Reason-Code: map(ais-active, reason-code) = {.parallel.}
    var AIS-ACTIVATE: object-class subtype-of ais-verb
    %Supplied:
     var ATV-Pname: map(ais-activate, DSA-name) = {.parallel.}
     var ATV-AFamily: map(ais-activate, address-family) = {.parallel.}
     var ATV-Address: map(ais-activate, real-net-address) = {.parallel.}
    %Returned:
     var ATV-Reason-Code: map(ais-activate, reasoncode) = {.parallel.}
    var AIS-INACTIVE: object-class subtype-of DSA-verb
    %Supplied:
     var INAC-Pname: map(ais-inactive, DSA-name) = {.parallel.}
    %Retnrned:
     var INAC-Reason-Code: map(ais-inactive, reason-code) = {.parallel.}
    var AIS-DEACTIVATE: object-class subtype-of DSA-verb
    %Supplied:
     var DAC-Pname: map(ais-deactivate, DSA-name) = {.parallel.}
    %Returned:
     var DAC-Reason-Code: map(ais-deactivate, reason-code) = {.parallel.}
    var AIS-ADD-ADDRESS: object-cIass subtype-of ais-verb
    %Supplied:
     var ADAD-Pname: map(ais-add-address DSA-name) = {.parallel.}
     var ADAD-AFamily: map(ais-add-address, address-family) = {.parallel.}
     var ADAD-Address: map(ais-add-address, real-net-address) = {.parallel.}
    %Returned:
     var ADAD-Reason-Code: map(ais-add-address, reason-code) = {.parallel.}
    var AIS-DELETE-ADDRESS: object-class subtype-of ais-verb
    %Supplied:
     var ADEL-Pname: map(ais-delete-address, DSA-name) = {.parallel.}
     var ADEL-AFamily: map(ais-delete-address, address-family)
    = {.parallel.}
     var ADEL-Address: map(ais-delete-address, real-net-address)
    = {.parallel.}
    %Returned:
     var ADEL-Reason-Code: map(ais-delete-address, reason-code)
    = {.parallel.}
    var AIS-RESOLVE-NAME: object-class subtype-of ais-verb
    %Supplied:
     var ARN-Pname: map(ais-resolve-name, DSA-name) = (II}
     var ARN-AFamily: map(ais-resolve-name, address-family) = {.parallel.}
    %Returned:
     var ARN-addresses: map(ais-resolve-name,
             set(address-family))
    computed-using arn-addresses(@@) = {}
     var ARN-Reason-Code: map(ais-resolve-name, reason-code) = {.parallel.}
    var AIS-SET-VECTOR-ATTRIBUTES: object-class subtype-of ais-verb
    %Supplied:
     var ASVA-Vector-Depth: map(ais-set-vector-attributes, integer) =
    {.parallel.}
     var ASVA-Vector-Width: map(ais-set-vector-attributes, integer) =
    {.parallel.}
     var ASVA-Filters: map(ais-set-vector-attributes,
             set(bloom-filter))
             computed-using asva-filters(@@)= {}
    %Returned:
     var ASVA-Reason-Code: map(ais-set-vector-attributes, reason-code) =
    {.parallel.}
    var AIS#GET-VECTOR-ATTRIBUTES: object-class subtype-of ais-verb
    %Supplied:
     var AGVA-Peer-Name: map(ais-get-vector-attributes, ais-peer)
    = {.parallel.}
    %Returned:
     var AGVA-Vector-Depth: map(ais-get-vector-attributes, integer)
    ={.parallel.}
     var AGVA-Vector-Width: map(ais-get-vector-attributes, integer) =
    {.parallel.}
     var AGVA-Filters: map(ais-get-vector-attributes,
             set(bloom-filter))
             computed-using agva-filters(@@) = {}
     var AGVA-Reason-Code: map(ais-get-vector-attributes, reason-code) =
    {.parallel.}
    var AIS-SET-VECTOR: objectclass subtype-of ais-verb
    %Supplied:
     var ASV-Peer-Name: map(ais-set-vector, ais-peer) = {.parallel.}
    %Returned:
     var ASV-Reason-Code: map(ais-set-vector, reason-code) = {.parallel.}
    var AIS-GET-VECTOR: object-class subtype-of ais-verb
    %Supplied:
     var AGV-Peer-Name: map(ais-get-vector, ais-peer) = {.parallel.}
    %Returned:
     var AGV-Vector: map(ais-get-vector, ais-probability-vector)
    = {.parallel.}
     var AGV-ReasonCode: map(ais-get-vector, reason-code) = {.parallel.}
    ais-gra.re
    #.parallel.
    Copyright (C) 1995 Xerox Corporation. All Rights Reserved. Copyright
    protection claimed includes all forms and matters of copyrightable
    material and information now allowed by statutory or judicial law or
    hereinafter granted, including without limitation, material generated
    from the software programs which are displayed on the screen such as
    icons, screen display looks, etc.
    .parallel.#
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    %%%%%%%%%%%%%%%%%%%%%%%%%%
    %        ais-grammar.cat
                          %
    %    To be included in the universal grammar file
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    %%%%%%%%%%%%%%%%%%%%%%%%%%
    agent-instance-service
                 ::=
                    ["agent-instance-service"
                 ais-name
                 ais-active-agent-list
                 local-probability]
                      builds agent-instance-service,
    ais-active   ::=
                    ["ais-active" "("
                    act-pname","
                    act-afamily","
                    act-address")"
                    "returns"
                    act-reason-code]
                      builds ais-active,
    ais-activate ::=
                    ["ais-activate" "(
                    atv-pname ","
                    atv-afamily ","
                    atv-address ")"
                    "returns"
                    atv-reason-code]
                      builds ais-activate,
    ais-inactive := ["ais-inactive" "("
                    inac-pname")"
                    "returns""
                    inac-reason-code
                      builds ais-inactive,
    ais-deactivate
                 ::=
                    ["ais-deactivate" "("
                    dac-pname")"
                    "returns"
                    dac-reason-code]
                      builds ais-deactivate,
    ais-add-address
                 ::=
                    ["ais-add-address" "("
                    adad-pname","
                    adad-afamily","
                    adad-address")"
                    "returns"
                    adad-reason-code]
                      builds ais-add-address,
    ais-delete-address
                 ::=
                    ["ais-delete-address" "("
    adel-pname","
    adel-afamily","
    adel-address")"
    "returns"
    adel-reason-code]
                      buiids ais-delete-address,
    ais-resolve-name
                 ::=
                    ["ais-resolve-name" "("
                    arn-pname","
                    arn-afamily * ")"
    %Above should probably be family name
                 "returns"
                 arn-addresses ","
                 arn-reason-code]
                      builds ais-resolve-name,
    ais-set-vector-attributes
                 ::=
                    ["ais-set-vector-attributes" "("
                    asva-vector-depth * ","
                    asva-vector-width * ","
                    asva-filters * ")"
                    "returns"
                    asva-reason-code]
                      builds ais-set-vector-attributes,
    ais-get-vector-attributes
                 ::=
                    ["ais-get-vector-attributes" "("
                    agva-peer-name * ","
                    agva-vector-depth","
                    agva-vector-width","
                    agva-filters")"
                    "returns"
                    agva-reason-code]
                      builds ais-get-vector-attributes,
    ais-set-vector  ["ais-set-vector" "("
                    asv-peer-name ","
                    "returns"
                    asv-reason-code]
                      builds ais-set-vector,
    ais-get-vector  ["ais-get-vector" "("
                    agv-peer-name")""
                    "returns"
                    agv-vector","
                    agv-reason-code]
                      builds ais-get-vector
    end
    authent.re
    #.parallel.
    Copyright (C) 1995 Xerox Corporation. All Rights Reserved. Copyright
    protection claimed includes all forms and matters of copyrightable
    material and information now allowed by statutory or judicial law or
    hereinafter granted, including without limitation, material generated
    from the software programs which are displayed on the screen such as
    icons, screen display looks, etc.
    .parallel.#
    !! in-package("RU")
    !! in-grammar('syntax)
    grammar AUTHENTICATION
     start-classes authentication-request, authentication-response
     productions
    authentication-request
                 ::= ["authenticate"
                 prin-2-be-authenticated
                 "{"
                 authentication-token
                 "}"] builds authentication-request,
    principal    ::= [principal-name] builds principal,
    dsa-name     ::= [dsa-name-value] builds dsa-name,
    token        ::= [token-string] builds token,
    %%%%%%%%%