3. Architectural Considerations
4. Informational Requirements
4.1 Entity Self-descriptions
4.2 Formats
5. Behavioral Requirements
5.1 Proxy protocols
5.2 Discovery Processes
5.3 Negotiation Processes
5.4 Configuration and Setup Processes
5.5 Task operation
|
The purpose of the protocol is the conveyance of self-descriptions, in terms of capabilities and explicit user preferences, of components interacting on some task and their operating environments and conditions, enabling negotiations on those descriptions and conditions, and construction of configurations and interface transformations according to the negotiations for accomplishing the intended task. |
There are two modes of interaction to be supported: asymmetric and symmetric. In asymmetric interaction one component uses the services of another component. For example, a person with a disability uses an Accessor, in the sense of the Archimedes project, to interact with a PC or a FAX. In asymmetric usage, one side may have no interface preferences expressed. For example, a server, in conventional client-server architectures, might not express any preferences whereas the client likely would.
In symmetric interaction, the components are "peers", in that neither side need be seen as user or provider of services. For example, in E-Commerce the interactions may be for the purpose of trading or negotiating. Another way of viewing this is to consider that a service user-provider or client-server model is an instance of the asymmetric mode, whereas the symmetric mode might be represented by collaborative interactions, such as chat, trading, white boards and the like.
Conceptually, two Accessors should be able to communicate in a symmetric mode. For example, at present two cellphones can communicate, through the cell network. Consequently, two persons with disabilities should be able to interact symmetrically, with the preferences of each being taken into account.
When interfaces are to be implemented with multimodal interactions, collaboration among modal-accessor elements will be crucial. An example of this is a military command post where speech, visual, audio and gestural controls must be coordinated. Each officer will have preferences based upon rank, experience, specialty and mission assignment, in addition to personal effects.
Preferences in symmetric-mode operation need not be entirely based upon the user interface configurations; preferences could be involved with a particular "face" or role the user wants to present in the interaction, as in role-playing Internet games, or, in E-Commerce, particular product/price combinations over which the participants will negotiate (e.g., "fixed prices are dead" scenarios).
Some systems could be considered to be hybrid, in the sense that they have elements of symmetry and asymmetry to them. For example, in E-Commerce, a buyer and seller could negotiate on price (symmetric) on items that the buyer selects from the seller's catalog (asymmetric).
The self-descriptions of the interacting entities will include:
The task to be accomplished will impose its own conditions on the operation. This information must also be conveyed to the process deciding upon the configuration and transformations necessary for the activity.
'Operating contexts' connotes a different, broader concept than a similar terminology in operating systems or user task environments (in usability, for example). Here it means not only what tasks are being worked on but what the platform is (e.g., PC running Linux), what conditions are present in the physical environment, possibly even the state of the user (fatigue, stress, how busy, etc.).
Constraints may be due to the conditions imposed by the operating context or by a physical limitation of the user. The limitation of the user might be due to an explicit disability or to an inability to use certain interface devices due to conditions or other activities the user might be concurrently engaged in. For example, a helicopter pilot would not use a mouse while in flight. Speech input and output might be limited by ambient noise from the rotors.
Preference negotiation, as such, is to be interpreted broadly. In some cases it will be merely implied, in that the characteristics provided will either match precisely or will not be accepted. The simplest instance of this case is when devices are coupled together with a hardwire "network", e.g., coupling through a serial port on a PC. In other cases, more extensive decision-making will be necessary, in extreme cases possibly requiring the use of special agents to determine whether or not a configuration or transformation is possible, given all the conditions that must be met.
There are four principal functions for interaction at interfaces between humans and systems:
These functions need not be orthogonal to one another. In fact, they commonly overlap. For example, a mouse is used for application control via the presentation on the monitor screen, and a touchscreen keyboard can be used for data input (consider an ATM with a touchscreen). Speech recognition can be used for both control and data entry.
Another "interaction function" that takes place among humans (or among systems, or systems and humans) is the Transaction. In a sense, all of the Interaction Functions listed above could be considered to be transactions, but a narrower interpretation is intended. What is intended is typified by exchanges in negotiation or collaboration, queries, responses to queries, and the like. Obviously, a transaction could be realized through one or more of the Interaction Functions above, but this need not be the case--transactions between systems need not involve the other Functions at all.
Any instantiation of these functions implies a context of operation, constraints on usage within context, and preferences and capabilities for realizing the function corresponding to context and constraint. In current computer systems in an office, for example, a mouse is used for control through pointing and clicking. The context here is the office and the computer is assumed to be capable of interpreting the mouse. A default preference is the mouse. However, a keyboard alternative is provided by Windows, for those users having Windows and able to use the alternative. Moreover, the office applications have interfaces designed with mouse-based control in mind and generally with the assumption of the user seated at a desk.
Contrast this now to a restaurant context, where the computer is used to determine seating, ordering and billing, and generally the user is not seated. Often the applications are designed for touchscreen or stylus control and a mouse would be entirely inappropriate for control input.
Then contrast this with a travel computer in a car where again the user is seated but may have both hands busy. Here neither a mouse nor a touchscreen is appropriate, but other modes of control input, such as speech, might be available. Note that this last example is functionally equivalent to a person seated in a wheelchair who has no effective use of his or her hands.
A disability can be expressed as a constraint to operation in some interaction function in some contexts. In this way, descriptions and preferences can avoid reference to any disability and be expressed entirely in terms of contexts and constraints, thus readily accommodating privacy concerns. A blind person might describe his or her preferences in presentation to be aural in relatively quiet contexts and tactile otherwise, without stating that he or she is sight-impaired in any way.
Sometimes a disability is irrelevant to a condition in a context. For example, a blind person who can read braille is generally able to read whether it is dark or light, quiet or noisy in the surrounding environment. On the other hand, a disability might be irrelevant in one interaction function but crucial in another. A person who has only a mobility difficulty might not be constrained by this disability in visual or aural presentations, but might be considerably constrained when control has to be actuated through the visual presentation--links in small font on the browser screen, for example.
|
The protocol requirements are specified in the context of a general architecture that is intended to capture most if not all of the functionality demanded by very broad applicability: the approach is intended to apply to all Information Technology environments envisioned now and for the future. Moreover, the approach is not intended to be limited to accommodation of people with disabilities, nor to a specific technology or set of technologies. Because of the wide range of possibilities that must be covered, multiple classes of behavior, from very simple to quite complex, must be included. For this reason, a single, all encompassing protocol is not envisioned. Rather, there should be a family of protocols, with core functionality, that correspond to the various levels of complexity encountered. By building around a core functionality, any new complexities (or simplifications) could be accommodated by just creating a new "family" member; an identifier in the initial handshake would determine the class to be used in any partiular instance. The architecture below must not be viewed as supplanting any existing or envisioned architecture or system, but as supplementing them to provide universal accessibility. |
The diagram below shows the general services arrangement for the accessibility protocols within the the communications hierarchy. The grouping shown is explained below. Except in the simplest realizations, the accessibility protocol "stacks" should be capable of being altered ad hoc to meet the service needs. This will be especially useful when complex collaborations or multimodal interfaces are to be configured. By not using fixed stacks, an implementation can build stacks as needed and attach them as needed to applications. One way of doing this is to use a stack template class and populate it, to create stack instances, with objects representing instances of protocol function classes. By following this approach, protocol functions may be downloaded when updates are necessary or when an entity does not have a protocol that is needed for some interaction
The Accessor/Transformer entity shown in the diagram couples a user's interface device to the communications system. It is analogous to the Accessor/TAP in the Archimedes architecture, but does not directly correspond to the Accessor/TAP functionality. In Archimedes, the communications corresponding to the communications described in this document exists between the Accessor and TAP. In the usage here, the communications has been conceptually split, with the Accessor doing some of its own communications independent of the Transformer, such as lookup and possibly negotation. The Transformer can be internal to the Accessor or it can be an external proxy. The Transformer and its functions are described farther below.
In asymmetric mode operation, the Accessor on the "server/target" side is replaced by a server/target application. In symmetric mode operation, both sides have Accessor/Transformer components.
The Immediate Services are for an operation that has previously been negotiated and setup, or which is a direct connection between the session initiator ("Initiator") and the responding entity ("Respondent"). For example, accessing a frequently used application or service would not need to be renegotiated every time. The Mediated Services provide for negotiating or updating operating features and configurations between the Initiator and Respondent, as well as for collaboration among a group of systems. A service or device used by a large number of different individuals, such as a kiosk, would almost always involve negotiation. However, if there were repeat sessions (e.g., a person using the same ATM week in and week out) the user might be "remembered" by the system and interaction could be handled by the Immediate Services instead. In such cases a repository becomes crucial to operation.
The Connection Technology provides for discovery and lookup access, as might be provided, for example, by Jini, CORBA or any of the home networking systems. It might also provide Transaction Services, to ensure that the preferences and capabilities are properly received and that negotiations, configurations and setup are received and committed to. When entities are not closely coupled (e.g., not on the same hardware platform or in a network where entity or service availability has some probability of failure) this transaction should be a two-phase commit protocol. For example, when the to communicants are distributed in the Internet, the two-pahse commit protocol should be used. When negotiation takes place an Accessor and a kiosk, the kiosk itself may be doing all the negotiation, configuration and setup, and the connection with the Accessor may be considered coupled closely enough that reliability is not a significant question. Here a two-phase commit protocol would not be needed, but each transfer of information would have to be acknowledged.
The Operation Services provide Session and Presentation level transfer of information (i.e., data, messages, control) between connected entities. The Immediate Services can use the Operation Services or the Networking Services directly. The Operation Services provide an "API", appropriate for accessibility or collaboration functions, for Networking Service protocols that are needed to support the interactions. This may not be needed in many cases, whereby the Networking Services protocols can be used directly. However, the configurations created as a result of negotiation may require coordination of the Networking Service protocols that cannot be anticipated by an application. Consequently, an "API"--a set of classes instantiated and arranged ad hoc in configuration and setup--will be necessary to provide the coordinated interface to the application. This may be more likely to occur with collaborations and multi-media/multimodal access than with other kinds of access (e.g., one-on-one messaging).
Networking Service is to provided by any networking technology appropriate to usage, including the Internet, IR and RF technologies, LAN technologies, power line technologies, phone line technologies, etc.
In the diagram below, Initiator and Respondent are two communicants; the Initiator begins the session ("is the calling party") and the Respondent is the entity with which the Initiator wishes to interact ("is the called party"). In the Archimedes architecture the Initiator corresponds to the Accessor and the Respondent corresponds to the Target Device. However, for the sake of complete generality, the Initiator need not be an accessor device--the Respondent may actually be an accessor system. The diagram assumes that discovery/lookup (see Section 5.2) has already taken place and that transfer of preference profiles and capabilities has been completed. The system is ready for negotiation to begin.
|
Proxies in this architecture are analogous to functions of the TAP in the Archimedes Architecture. However, unlike TAPs, the proxies may be part of the entity that invokes them. In this situation a protocol (or internal interface) specific to the invoking entity connects the two. Like TAPs, they could also be physically separate from the invoking entity, connected to it by proprietary protocol or by a standard protocol. In some situations, all of the proxies shown--for one communicant--could be contained in a single entity. Any of the proxies could be implemented within Initiator or Respondent or totally separately as agents, devices or other servers. Any of the Protocols in this diagram can be virtual. That is, they could be implemented, not as explicit protocols like TCP, but perhaps as parameter passing in local method invocations or even database queries. This may be especially true of the protocols which are specific to an entity, such as the Intercession protocols described farther below. [Such protocols may be proprietary to a device or system or may require special implementation. Discussion of them is beyond the scope of this document.] Some of the proxies, e.g., the Negotiation and Configuration proxies, may be in fact implemented on one or the other of Initiator or Respondent. Similarly, Repositories could be locally implemented or could be network services. For example, an ISP might offer repository services to its customers. |
The Intercession Proxy provides the ability ("intercedes") for an entity to execute a Transaction Protocol during preference negotiation, when one is necessary (e.g., the entity is not powerful enough). The Intercession Protocol may be entity-specific. The Negotiation Proxy possesses the ability to perform negotiations on preferences and capabilities. It passes the results of this negotiation back to the communicants and to the Configuration and Setup Proxy. The negotiations can be very simple, i.e., direct attributes matches, or more complicated, with preferences that influence one another or with acceptable ranges of behavior as an expressed preference. This will depend greatly upon the nature of the interacting entities and their preferences and capabilities. Having been presented the preferences and capabilities negotiated by the communicants, the Configuration and Setup Proxy decides how to configure the system between the communicants and what information is necessary to setup the interaction. This agent may use decision theoretic means to determine and optimal configuration (if one exists), or it may be simple table lookups based upon attribute matching, depending upon the nature of the communicants' profiles. When this has been accomplished, the communicants are informed and the proxy sends each communicant the appropriate information to set up the interactions.
Once the preferences and capabilities have been realized in a configuration, the communicants can begin to interact with one another. In order that the preferences and capabilities are respected during operation, it may be necessary to perform transformations on data passing between the communicants. This is exactly analogous to TAP operation in Archimedes. There are two modes: 1) an operation protocol carries information to a Transformer Proxy of the other communicant, which transforms the information and passes it via an entity-specific protocol for interface use; 2) an entity-specific protocol sends data to its associated Transformer Proxy, which transforms the data and passes it via an operation protocol to the other communicant. This is necessary because not all of the transformations that are to be made are consistent with only one mode of transfer. A simple example of transformation is speech-to-text. The speech can be converted to text before being sent, or the speech stream itself can be sent and converted when received. Clearly, this depends upon the nature and capability of the device where the speech is input. If neither the sending nor receiving devices is powerful enough, proxies will be required. This might occur when the sending device is a wireless unit with microphone input and a vocoder, and the receiving device is an appliance that understands only text-based commands.
Because every user will have different needs, and systems and collections of devices may have configurations that change with every session, it will be necessary to use self-descriptions of entities to provide flexibility. This information is used to determine operating conditions and configurations for a given session, and to support dynamic changes in these conditions and configurations during a session. These operating conditions and configurations are the result of negotiation, either by one of the communcicants or by a neutral party. Simple descriptions will almost always result in simple negotations (may be only attribute matching), while complex descriptions will often result in complex negotiations, including such things as matching an offer to a range (similarity), weighted decision models and counter-offers.
The self-descriptions, referred to as Profiles, include: information about the user's working context; about the task that is to be performed; what kinds of constraints are placed on how the task is accomplished, e.g., by the working context or by limitations of the user; what solutions the user prefers to apply to ameliorate the constraints; platform and communications capacities; device capabilities and limitations. However, not all sessions will use or even have this information, depending on what the interacting components are and what is to be done. For example, in coupling a headtracker to a computer through a wireless connection, the profile might only state that for all contexts, this user prefers the head tracker as a pointing device to be used for control and data entry, and that visual presentation is preferred in all contexts. Note that no mention is made of a disability for the user. In fact, this user might not be disabled at all, but merely does not have hands free to operate a mouse and keyboard. It is important for privacy protection that any characterization of a user's disability not be present in a profile.
More complicated profiles could occur because the user is affected by noise or heat, for example, or because a tactical military situation prevents high light levels on a screen. A user might also find after a while that he or she is becoming fatigued or that the cognitive load in the presentation is too high. Again, these could be related to disabilities or not at all. The profile structure, therefore, must be able to handle various levels of complexity. In order for this to occur, there needs to be an abstract description language to provide the flexibility of structure is required. This would enable implmentation approaches appropriate to the complexity.
A profile is made up of Interaction Parameters, as described below. In practice, a profile may be "sparse", i.e., not completely filled. For example, when "widely recognized" defaults are to be used, there is little need in specifying their characteristics--the defaults could be referenced by a standard code or just applied indiscrimininantly when nothing is specified for them. Similarly, when a Parameter is frequently invoked by a user, it could be referenced by a code. A Parameter might be irrelevant to a given operating environment and could just be ignored. A Preference might be chosen to apply no matter what the context. For example, a user with a disability might have an accessor which has a breath switch. Regardless of the context, the user has but this one choice.
Interaction parameters consist of the Task and the Interaction
Functions that it uses, the Contexts, the Constraints and the Capabilities
and Preferences. The sense of this is that Task, Context and Constraints
determine a set of possible choices for interface elements. The user then
states (explicitly or implicitly) a preference among these choices for the
session. It is also possible to change preferences within a session
whenever changes within the Task, Context and/or Constraints occur. Thus,
for example, a user on the bridge of a warship may want to change to a dim
navigation display when night comes on to avoid unnecessary light that may
betray position. The diagram below shows the structural relationship of the
Task, Context and Constraints. The interpretation is that the Interaction
Functions of the Task are constrained within a given context. The
constraints may be dependent or independent of context and may be different
for each context of consideration. It is also possible that a constraint is
irrelevant to a context or does not exist for a given context. Each of the
parameters is discussed in more detail below. Capabilities are not task
dependent in general, but capabilities must be properly matched with Task
Interaction Functions in order to carry out the assigned task.
A context consists of several environments which may be interrelated. Three primary environments are:
The Physical environment consists of the physical area where the user is located and the conditions of that area. For example, the Physical environment of an office might consist of a user space (in a room or cubicle), air temperature and humidity, lighting, furniture, and noise level. The Computing environment in this office might consist of Windows 98 (or MacOS or Linux) in a client-server system. The Personal environment might include time of day, levels of stress, fatigue, physical strain, discomfort. As another example, when accessing an ATM, the Physical environment might describe the area around the ATM, the air temperature and humidity (is it hot? is it raining?), lighting around the ATM, and noise level. The Computing environment might consist of the ATM embedded processor and wireless access to it. The Personal environment might be the same as for the Office example, but because ATM access is momentary and office usage is sustained over a period of time, the effects of the Personal environment are not as likely to be a factor. Personal environment becomes more critical when the Physical environment factors are likely to cause stress or fatigue, such as in a fighter cockpit. Computing environments are important to the extent that they condition the usage and interface configurations possible. For example, the computing environment for a hand-held wireless device is different than that of an office PC on an extensive intranet.
The preference model is not a user model, but some preferences may be derived in some cases from a user model. In general, preferences represent an opposing concept to the user model, in that preferences more explicitly represent an individual in contrast to a user model which is usually the aggregated characteristics of many individuals. "Default" preferences may in fact be those of a large number of persons. For example, at present a default preference is the use of a mouse in a windowing environment in a home or office context, since millions of people successfully use a mouse in this situation.
Preferences are almost always context, task and constraint dependent. They are similar in some ways to capabilities in that given a set of capabilities (ways of doing something), a user makes a choice--states a preference--among the capabilities to accomplish a task in a given context with certain constraints.
Sources of preferences can be from direct input by a user (or someone acting for a user), from intelligent agents observing the user's behavior, from user models or from usability studies.
Capabilities in this usage have as much to do with the capability of a system or device to transform objects for interface adaptability as for device characteristics. For example, if a user is trying to use a simple appliance, the appliance probably will not have the processing power to provide interface transformation for the user. When capabilities and preferences are examined, it will be clear that some kind of proxy is needed to do the transformation. In HomeAPI, this might be an object added to the API which performs this when needed, as an adjunct to the device properties checking function. Capabilities are not task dependent in general, but capabilities must be matched up with Interaction Functions in order to carry out the assigned task. For example, control input should be carried by a channel with as low a latency as possible. On the other hand, high bandwidth is needed for high volume transfers, and latency is of little concern. In accommodating a disability, the capabilities of the accessing device are as important as those of the target system or device. A wireless accessor using speech input may not have the power of converting the speech to text before transmitting. Similarly, it may not have the ability to convert received text back to speech.
|
A Constraint can be thought of as anything that limits the efficiency and/or effectiveness of the user to employ particular instances of Interaction Functions. |
Impaired vision, for example, limits a user in employing visual means of Presentation. However, the person's vision might be impaired not by physical disability but by law, because some state does not permit a video screen in an autmobile that can be seen by the driver. Persons who cannot use their hands, because of a disability or because their hands are busy with other activities--perhaps flying a helicopter--are limited in their means of employing hand-activated Control and Information Input devices. A Presentation might need to be limited in complexity because the user has a cognitive disability or because the operating environment is high stress and the user is cognitively overloaded--perhaps a fighter cockpit in combat.
Clearly, there is a wide interpretation to be had for Constraints. They can be the result of disability, of conflicting user activities, of the context or environment of the user and the system, or of the state of the user. As indicated in the Interaction Parameters diagram above, categories of Constraint include: Physical, Cognitive, and Emotional.
|
A task may be considered to be a collection of different instantiations of Interaction Functions. |
Since Tasks can be thought of as being made up of Interaction Functions which are invoked in sequences or in groups to accomplish some goal, Task descriptions must give some sense of what is to be done and what functions are necessary to achieve it. Ideally, task analysis for the most common types of tasks will done off-line; then a simple index into a repository would be used for selection. Simple tasks, such as pointer actions (i.e., from mouse, touchscreen, eyetracker, etc.) may require only simple descriptions. Other kinds of tasks may involve complex collaborations and very complex descriptions. Some descriptions may not be adequate to make an automated analysis, and human intervention could be required.
Some common tasks are:
Capabilities will indicate the ability of one side or the other to handle such tasks. For example, one side may wish to control a device in some aspect. If the device does not provide access to that control, then the task cannot be accomplished. Access control (security) may also be considered a capability. If, for example, access is requested to write into a military database, and the user has no authorization to do so, then the task cannot be accomplished. In this sense, the protocol proposed might be successfully used in role-based access.
A task in a given context under certain conditions will provide a set of possibilities for preferences. In certain combinations, there may be no choice, or a preference may be meaningless.
A general format for expressing a profile is shown below. When only capabilities are being conveyed, the Preferences part is empty. This would be typical of a Respondent in an asymmetric mode of operation. A communicant might also transmit only the Preferences part. Any entry may be empty. Each Interaction Function has its own set of Contexts and Constraints, because one Function may be differently affected by a context or constraint than another. This may result in some duplication, but it is necessary to maintain flexibility. The structure implies that a hierarchical description language would be useful in describing the format for transmission.
Since proxies are used whenever a device or system does not have the power to communicate, negotiate or execute certain operations on its own, protocols between the device and the proxy are required. However, since these protocols may be device-to-proxy network and device dependent, any details are out of the scope of this requirements specification. However, a proxy protocol must be capable of carrying pertinent information from or to the entity it represents. For example, consider a proxy for an accessor to a kiosk and that the accessor is an RF-linked device that is only capable of transmitting identification and preference information. The user prefers to interact with the kiosk through the kiosk's own speech input and output devices. The accessor is not capable of receiving any information from the kiosk (e.g., it might be a smart card). The proxy then negotiates with the kiosk for the user and notifies the user when setup is complete. Since the user has chosen audible output, this could be done by a simple audible signal or a spoken "OK". Note that a spoken "OK" is likely to be understood by almost all (hearing) users regardless of language, since it is used throughout virtually the entire world.
A protocol that an Initiator (Respondent) uses to invoke discovery (respond to a discovery request) is needed above the actual discovery service (of the Connectivity Services) in order that receipt of the transmitted data for identification and preference profiles can be acknowledged. This is especially critical for collaborations and multimodal sessions. The protocol must cover the situations where a system or device is only making itself known to the repository, is providing a profile, or is updating a previous profile. It also must cover the case when a previous profile is to be used again and a simple reference to it is provided. The diagram below shows the elements involved in the Discovery Process.
The Discovery Processes consist of Indentification, by which an Initiator makes itself known to the "universe" in which it exists or intends to operate, and Preferences Declaration, in which the preferences of the user are declared to ameliorate the operating conditions. At a minimum, Identification consists of providing a locator and a description of what the entity is (e.g., a computer, a device, an appliance, a service). In the general case depicted in Section 3, the Initiator is represented in this by a proxy, when the Initiator is not be powerful enough to handle the communications on its own. (The Respondent may also have a proxy for the same reason.) In any session, an Initiator has either made itself known previously or it has not. The Discovery protocol must be capable of handling both of these cases. The Discovery Process is supported by a Lookup Service in the Connectivity Service. An Identification session can have five purposes.
If a Respondent is unknown, then discovery through the Connectivity Service is needed to locate a Respondent before communication can begin. Since the Respondent is presumably unknown, it must be found by characteristics that the Initiator provides. If such a Respondent has not previously registered, then the session cannot be established.
In any case, the preferences profile is not actually sent to the Repository until the Repository requests it. This is necessary to ensure that the Respository has actually received the Identification Request and is able to act upon it.
The Preferences Declaration proceeds when Identification has concluded and consists of a request to an Initiator for a preferences profile, as described in Section 4. This activity may also include a request to a Respondent for capabilities and, in the symmetric mode, a Respondent preferences profile as well. Each of the communicants should acknowledge receipt of the request before the Negotiation Process (below) can begin.
The functional requirements outlined above are the basis for the grouping of discovery activities into Mediated and Immediate Services, as discussed in Section 3.
When the network and connectivity is such that there is a possibility that a resource (e.g., target system accessor or negotiator agent) might not be available because of network or host crashes or overloading, a two-phase commit transaction protocol may be necessary to assure that negotiation transactions are completed. This may not be necessary when operating in a tightly coupled or robust network system (e.g., a home network) where unavailability of a resource is unlikely or negotiation is infrequent. It may also not be needed when when unsophisticated negotiation (i.e., simple atrtribute matching) is used. However, some form of commit and acknowledge must be used when every session requires negotiation, such as in public kiosks, ATMs and automated POS terminals. It is also crucial in collaboration or other "federated" activities.
The form of the preference profiles will determine the degree of negotiation required. Simple attribute matching generally will not require the active participation of the prospective communicants. On the other hand if there are several options presented for some property or preference, agreement by the prospective communicants may be necessary to make the decision before configuration can take place.
In any case, the Negotiation Process should proceed as follows:
The negotiation entity will obtain the preferences and capabilities information from the Repository. If the negotiation entity is not co-located with the Repository, then a separate protocol will be necessary to tranfer this information from the Repository to the negotiation entity.
Once profiles from the communicants have been negotitated, it will be necessary to convey information on configurations and for setting up the interaction. This can range from very simple information, e.g., how to couple to a device's driver and what data types will be used, to very complex, e.g., locators, interfaces and protocols for agents, proxies and collaborators. Since this information is critical to the success of the interactions, it needs to be reliable.
The actions required for Configuration and Setup are
Operation of tasks will often require protocols to communicate from one system to another. For example, in ATM operation, once contact has been made and the ATM's interface is configured according to customer preferences for the task, it remains to get particular data regarding the banking transaction (e.g., dollar amounts) to the ATM. Because the system may be using wireless communications for this and because of the criticality of the transaction, some form of reliable interaction must be used. A full two-phase commit transaction protocol is not warranted across the accessor link, but some form of commit and acknowledgment is necessary to assure the customer of the local completion of the transaction. Other protocols will be required to send interface actions and events to the ATM, and ATM reactions back to the customer's device interface. These could be "lower" level protocols with low latency. If the user happened to be using speech input, this might be transmitted directly to the ATM for recognition processing. This would require a different protocol than if (speech-to-) text were being used on the customer's device. If this same device is now used for obtaining street traffic information (perhaps the customer is blind), still a different protocol might be used.
This suggests that protocols might not exist in the device as fixed stacks but temporary stacks which would be built ad hoc from classes representing protocol functions and attached to the application/user interface as needed. If this approach were used, then protocol functions that a device did not have could be downloaded from a class library. Stack skeletons would be used for commonly occurring protocols. But this also means that some form of coordination function and interface will be needed in order to present an application a common way of using the protocols instead of a variety of different interfaces. While this is not necessarily an implementation issue for simple environments, with collaboration and multiple interaction communications it will be important to developers.