Question/Answer Transaction Protocol Use Cases

Second Committee Working Draft
NISO Committee AZ
June 19, 2003

NISO Committee AZ is developing a Question/Answer Transaction (QAT) Protocol (QATP) to support exchange between Digital Reference systems collaborating in the processing of a question. This is one of a set of committee documents related to the development of the protocol:

• Overview
• Functional Model
• Use Cases (this document)
• Protocol Specification
• Implementor Guidelines and Recommended Practices

This document describes the activities and specialized capabilities needed in the protocol, from a user perspective.

NISO Committee AZ requests review and comments from interested parties. Please send comments by November 7, 2003, to rden@loc.gov.

Assumptions

The use cases below generally assume two systems, A and B, which exchange QATP messages. QATP is a client/server protocol; typically, A is the client and B is the server, and (as reflected in case 1.1 below) A receives a question from a user, sends the question to B (via the protocol), and B supplies the answer (also via the protocol; the protocol mechanics are not described in this document however).

Protocol exchanges are described in terms of transactions. Modeling of transactions is more formally developed in the Protocol Model document. But the concept of a transaction is central to the development of use cases so we list here relevant characteristics of transactions:

• A transaction is a set of messages exchanged between a client and server pertaining to the processing of a particular question. The client assigns a distinct transaction identifier, carried in all messages for that transaction.
• A transaction is always two-party, involving a client and server. Some use cases describe three (or more) systems however even then QATP remains a bilateral (client/server) protocol. Thus in cases where there are for example three systems (A, B, and C) there are multiple transactions (multiple instances of the protocol), for example, one between A and B and another between B and C, or, one between A and B and another between A and C.
  
• A client may send a question in several parts (i.e. several messages). All question parts sent within a given transaction collectively constitute a single question; that is, a transaction corresponds to a single question, from the protocol perspective. In reality, two unrelated question might be bundled into the same transaction, or two parts of an apparently single question might be split into two transactions. For example a user might as a client "where and when was Abraham Lincoln born". The client may treat this as a single question (single transaction) or two questions -- "where" and "when" (two transactions). Or as another example, a user might ask: "What high schools are in Bethesda, Maryland; and who was the winning pitcher in game seven of the 1924 World Series" and though these may seem to be two unrelated questions the client might treat this as a single question (single transaction). The decision of how a user's question is to be treated in this respect (single or multiple questions) is beyond the scope of the protocol.
• A client may carry on multiple concurrent transactions with a given server. Thus a client may send two question messages to the same server, with different transaction identifiers, and they will be distinguished as belonging to two different transactions and thus parts of different questions, or with the same identifier and they will be understood to belong to the same transaction and thus parts of the same question.
• A client may have several active questions being processed concurrently by several servers, but these are different transactions (even if it is the same question).
• A transaction may be "closed", by the client or server.
• A closed transaction may or may not be "archived".
• An active transaction may reference a closed transaction. Unless archived, however, the referenced transaction might no longer be available.
• A transaction may remain open indefinitely; it need never be closed. Theoretically it can continue forever.
  

Use Cases

0. Simple Question/Answer, Non-protocol.

In the following use cases A has received a question from a user.

• Use Case 0.1: Answer immediately. A chooses to answer the question itself immediately.
• Use Case 0.2: Answer asynchronously. A chooses to answer the question asynchronously, telling the user to expect an answer later and contacting the user via e-mail or some other means.
• Use Case 0.3: Private channel. A chooses to open a separate (synchronous or asynchronous) communication channel with B. This is a private channel, not involving the QAT protocol. Using this channel, A asks the question and B answers it. A then provides the answer to the user in the context of the still-open session.

The above cases are included for completeness; they impose no requirements on the protocol (this point is elaborted in the model document). In the remaining cases communication between systems (A, B, C, etc.) is via the protocol; unless otherwise specified, assume A has received a question from a user, has chosen not to answer all or part of the question itself, and has sent all or part of the question to B.

1. Simple Question/Answer, Via Protocol
   
   
   • Use Case 1.1: Simple QA. A sends the question to B, requesting an answer. B processes the question, determines the answer and sends it to A who then supplies the answer to the user.
     
     
2. Multipart Question
   • Use Case 2.1: Basic multipart question. A splits a question into several parts, send the first part, then the second, and so on.
   • Use Case 2.2: Supporting information. After sending a question, A subsequently realizes that there is additional supporting information that also needs to be supplied, so sends another (second) part of the question, then perhaps a third part, and so on.
   • Use Case 2.3: Parts sent as available. A hasn't completely formulated the entire question, but has formulated enough to send the first part, so that B might be able to begin processing. A send the first part, and subsequently sends additional parts as they are formulated.
     
     
     
3. Multipart Answer
   • Use Case 3.1: Basic multipart Answer. B splits the qnswer into several parts, send the first part, then the second, and so on.
   • Use Case 3.2: Parts sent as available. Part of the answer is available in a relatively short time while the complete answer will require considerably more time. (Or similary, a less detailed answer is available in a relatively short time while a more detailed answer will require more time.) B partially processes the question and sends the available part of the answer to A, subsequently sends another part of the answer, continues to send answer parts as they become available, and eventually sends the last part.
   • Use Case 3.3: More information. When B supplies the first part of the answer, B isn't certain that there will be any additional information forthcoming, but subsequently, more information becomes available which B then supplies.
     
   • Use Case 3.4: No more info. B supplies one or more answer parts, and indicates to A that there are more answer parts to come. Subsequently B decides that there is no more information (and therefore no more answer parts) and so informs A.
   • Use Case 3.5: Answer split up logically. B decides that the question as submitted, although a single question part, is logically several questions that it prefers to answer in separate parts.
   • Use Case 3.6: Mutipart Intermediary. B decides that the question is logically several questions, and for each, there is another system who is more appropriate to answer it. Thus B (acting in a client role) sends the questions to the various systems and awaits answers, and then (back in the server role) sends the answers in separate parts to A as they become available.
   • Use Case 3.7: Partial intermediary. B breaks the question into parts, some of which B can answer and others it can't. B answers those it can, and those it cannot answer (as in the previous case) it sends to other systems, awaits answers, and sends the answers to A.
   • Use Case 3.8: Answer what you can. B breaks the question into parts, some of which it can supply answers for (either B can answer it or B sucessfully finds another system who can) and others it can't. B supplies answers for those it can, and informs A of the failure to obtain answers for the others.
     
     
4. Additional Multipart Cases
   • Use Case 4.1: Supporting info. A sends a question to B, who sends an answer-part (indicating more to come) and as a result of the partial answer, A realizes that it needs to send supporting information (perhaps B didn't understand the question, or perhaps the partial answer reminded A of another part that it forgot to ask). So A sends another question-part.
   • Use Case 4.2: Server waits. B sends what it thinks is the whole answer, based on the question as submitted so far. But B isn't certain that A has yet sent all of the question (might send more parts). So B leaves open the transaction and subsequently receives an additional question-part.
   • Use Case 4.3: Follow-up. B sends a (final) answer (and leaves open the transaction). A then sends a follow-up question, which B answers.
   • Use Case 4.4: Unrelated follow-up. As in the previous case A sends a what it considers to be a follow-up question. However, B deems it to be unrelated to the earlier question and prefers that it not be part of this transaction, and so informs A. A sends the question in a new transaction.
   • Use Case 4.5: Simple correspondence. B sends the answer in parts that correspond to the question parts, and B indicates which question part each answer part corresponds to.
   • Use Case 4.6: Complex correspondence. Some of the answer parts correspond one-to-one with question parts, in some cases an answer part correspond to a number of question parts, in other cases several answer parts correspond to a single question part, and finally, some answer parts don't correspond directly to one or more question parts. B indicates for each answer part the correspondence.
5. Clarification
   
   
   • Use Case 5.1: Simple clarification. While processing a question B determines that clarification is required, requests and receives clarification from A, and proceeds.
   • Use Case 5.2: Intervening clarification. A sends a question to B, who sends an answer-part (indicating more to come) but during further processing realizes it needs clarification. So B requests and receives clarification, and then sends additional answer parts.
   • Use Case 5.3: Later part clarification. A sends a question to B, who sends an answer-part (indicating more to come) and then A sends another question part. B needs clarification for the second question-part. So B requests and receives clarification, and then sends additional answer parts.
   • Use Case 5.4: Specific part. As in the previous case B needs clarification for a specific question-part. B requests clarification, indicating the specific question part.
     
   • Use Case 5.5: Clarification not provided, no problem. A sends a question to B who requests clarification. A never provides clarification, but B eventually sends an answer anyway.
   • Use Case 5.6: Clarification not provided, problem. As in previous case A sends a question to B who requests clarification, which A never provides. In this case however, B waits for the clarification, eventually gives up and terminates the transaction.
   • Use Case 5.7: Asynch clarifications. B requests clarification from A, and before receiving the clarification, determines that yet additional clarification is needed independent of the first clarification. So B sends along the second clarification request even before receiving the first clarification. Subsequently, A sends both clarifications (possibly out-of-order but they are properly matched by the protocol).
   • Use Case 5.8: Clarification combined. Similarly B requests clarification from A, and sends a second (independent) clarification request even before receiving the first clarification. Subsequently, A sends a single clarification addressing both requests.
   • Use Case 5.9: One request, multiple clarifications. B requests clarification from A, who sends a clarification, and then realizes that there is additional clarification pertaining to that single clarification request, so A sends along the additional clarification.
   • Use Case 5.10: Patron redirected for clarification. B requires clarification and sends a message to A requesting that the user contact an individual at B for clarification (and includes contact information). A passes the information to the user who contacts the individual at B and clarifies the question. B then proceeds with processing of the question.
     
     Note: The following two cases do not have any protocol implications, and are included for completeness.
     
     
   • Use Case 5.11: Local clarification. A receives a question from a user, requires clarification of the question, and sends a message to the user requesting the user to contact an individual at A (and includes contact information). The user contacts the individual and clarifies the question. A subsequently supplies the answer to the user.
   • Use Case 5.12: Local, synchronous. Similarly, A requires clarification and requests the user to contact an individual at A, and the user clarifies the question. A provides the answer before the session ends.
     
     
6. Transaction Progress
   

   Terminology related to transaction progress is used as follows:

   Suspend and resume refer to suspension and resumption of processing of the question, by the server.
   Close refers to ending the transaction (by either party).
   Terminate refers to premature closing of the transaction, by the server.
   Cancellation refers to termination, at the instigation of the client (i.e. the client request termination).
   Failure is the inability of the server to process a question.
   Completion refers to normal completion of processing the question, as well as of the transaction.

   This terminology (used in this as well as other sections of this document) is intended for descriptive purposes only and has no protocol significance.
   
   
   Status Reporting
   
   
   • Use Case 6.1: Status request/response. A sends a question to B. While B is processing the question, A requests the status of the processing of the question. B responds with a status report.
   • Use Case 6.2: Status request ignored. Similarly, while B is processing the question, A sends a status request. B ignores the request.
   • Use Case 6.3: Unsolicited Status report. While B is processing the question, it sends regular (unsolicited) status reports on the processing of the question.
     
     Suspend/resume
     
     
   • Use Case 6.4: Suspend/resume. A requests B to suspend processing until further notice. Subsequently A requests B to resume processing.
   • Use Case 6.5: Suspend/cancel. A requests B to suspend processing until further notice and subsequently cancels (requests B to terminate) the transaction.
   • Use Case 6.6: Automatic resume. A requests B to suspend processing until a specified time. B suspends, and then automatically resumes resumes processing at the specified time.
   • Use Case 6.7: Early resume. A requests B to suspend processing until a specified time and subsequently (before the specified time) requests B to resume.
   • Use Case 6.8: Early cancel. A requests B to suspend processing until a specified time and subsequently (before the specified time) cancels the transaction.
     
     
     
   Cancellation
   
   
   • Use Case 6.9: simple/cancellation. A sends a question to B and subsequently cancels the question.
   • Use Case 6.10: multi-part/cancellation. After B sends the first answer answer part, A is is not interested in receiving further parts (perhaps A is satisfied by the first part, even though B has more parts to send). A cancels the remaining parts.
   • Use Case 6.11: clarification/cancellation. B sends a clarification request, and instead of supplying a clarification, A cancels the transaction.
   • Use Case 6.12: no-answer/cancellation. A sends a question and receives no answer for a long time, and so cancels.
   • Use Case 6.13: messages after cancellation. A cancels a transaction, and considers it to be closed. A continues to receive messages for that transaction, for example, B may have sent a message before receiving the cancellation. A discards the messages.
   • Use Case 6.14: rejected cancellation. B receives a cancellation, but continues to send messages pertaining to the question (A is not authorized to cancel, or B does not agree to the cancellation).
     
     

     Failure

   • Use Case 6.15: Failure notification. A sends a question to B, who cannot answer the question (can't answer it itself, can't find anyone else who can, or doesn't choose to try to). So B sends a failure notification to A.
   • Use Case 6.16: Abort notification. B sends one or more answer parts, but before sending the final answer part finds it must terminate the transaction. So B sends a termination notification to A.
     
     Completion
     
     
   • Use Case 6.17: Normal completion. B sends an Answer part and says "this is the final answer and the transaction is closed."
   • Use Case 6.18: Retroactive completion. B sends one or more answer parts, and then realizes that the last answer was really the final answer, even though B had indicated there was more to come. So B sends a Close notification to A.
     

     Neverending Transaction
     

   • Use Case 6.19: No conclusion. A continues to send question parts and B sends answer parts, and neither closes the transaction, which remains active indefinitely.
   • Use Case 6.20: No final answer part. A sends a question to B, who sends many answer parts and never a final answer part; neither closes the transaction, which remains active indefinitely.
     
   • Use Case 6.21: Dormant. A sends a question to B, which is the only message of the transaction, however neither A nor B closes the transaction, which remains open indefinitely.

   Note: The implication of these use cases is that the protocol should not require that all transactions must necessarily eventually close. These cases are included to foreclose the possibility of that requirement.(in contrast to most use cases which reflect requirements).

7. Constraint
   Constraints take a number of forms. Typically, A sends a question to B and before (or during) processing of the question, B imposes a constraint. It may be a binding constraint that A must agree to before B will begin processing, for example, A must agree not to archive the answer. It might require A to make a choice. It may involve negotiation. It might be "informational" (not require consent). It might be imposed by the client (rather than the server).

   Consent

   • Use Case 7.1: Consent granted. A sends a question to B, who sends a constraint to the client, indicating "must respond", that is the client must agree to the constraint in order for the transaction to continue. The client responds affirmatively and the transaction proceeds.
   • Use Case 7.2: Consent denied by server, client cancels. B sends a constraint to A, indicating "must respond". A responds that it does not agree to the condition, and cancels the transaction.
   • Use Case 7.3: Consent denied by server who terminates. Similarly B sends a constraint indicating "must respond" and A responds simply that it does not agree to the condition. B then terminates the transaction.
   • Use Case 7.4:Authentication. B needs to authenticate a client to see if it is authorized to receive the answer. B sends a constraint message (must respond) demanding authentication information.
     

   
   Informational Constraint

   • Use Case 7.5: Implied consent. A sends a question to B, who sends a Constraint message without indicating "must respond", For example, "processing will take 2 days". If A agrees with the constraint it need not respond.
   • Use Case 7.6: Implied consent denied. Similarly B sends a (need-not respond) Constraint message: "processing will take 2 days". However A does not agree with the constraint and cancels the transaction.
   • Use Case 7.7: Resource information. B sends a Constraint message which may contain resource or quota information, for example "you're funded only for two remaining hours" or "your quota for the month will expire with two more questions". A need not respond.
   • Use Case 7.8: Obligatory notice. B attaches a constraint to an answer (or answer-part). For example it might be a copyright statement, or it might be a constraint that B knows that A is already aware of, but B is obligated to send it.
     

   Known Condition

   • Use Case 7.9: Servers knows limitation of client. B sends a Constraint message indicating "I need to impose this constraint, that I already know you can't agree to" and concludes: "therefore the transaction is terminated".
   • Use Case 7.10: Server knows limitation of self. B sends a Constraint message indicating "I cannot comply with a constraint that I know you need" and concludes: "therefore the transaction is terminated".
   • Use Case 7.11: Preemtive compliance. B sends a Constraint message indicating compliance with a constraint that it know that A must impose.

   Client-initiated Constraint

   • Use Case 7.12: Consent granted by server. A sends a binding (consent required) constraint. B sends a reply agreeing to the constraint.
   • Use Case 7.13: Consent explicitly denied by server. A sends a binding constraint. B cannot comply, so sends a reply rejecting the constraint. A then cancels.
   • Use Case 7.14: Consent implicitly denied by server. A sends a binding constraint. B cannot comply, so terminates the transaction.
   • Use Case 7.15: Prior Constraint. A begins a transaction with a constraint message, for example "I need assurance that you will keep this question confidential before I send it".
     
     

   Accompanying Constraint

   • Use Case 7.16: Constraint Accompanying Question. A attaches a constraint to a question-part.
     
   • Use Case 7.17: Constraint Accompanying Answer. B attaches a constraint to an answer-part.
     

   Partial Constraint

   • Use Case 7.18: Partial-prior. B sends an answer in three parts where only the second part is constrained. B sends a constraint message prior to sending the first part, saying, for example: "The first and third parts of this answer may be stored and re-used. The second part of this answer is proprietary information which you may see in the context of this exchange, but which may not be archived or re-used in any way."
   • Use Case 7.19: Partial-accompanying. Similarly, B sends an answer in three parts where only the second is constrained; however, the constraint requires consent. So B sends the first part with an accompanying constraint field indicating "no constraint on this part"; then sends a constraint message, receives a response (agreeing to the constraint), and sends the second part; then sends the third part with an accompanying constraint field indicating "no constraint on this part".
     

     Complex constraint

   • Use Case 7.20: Negotiation. A sends a question to B, saying "I need the answer in 1 day". B sends a Constraint message saying "Normal processing will take 2 days. One-day processing will cost you an extra $50. Which do you want?" A responds, either selecting one of the two choices, or rejecting them both.
     
   • Use Case 7.21: Multiple concurrent constraints. B has a number of constraints to impose (/propose) and sends a number of Constraint messages (asynchronously).
   • Use Case 7.22: Consent denied, new constraint issued. B sends a constraint for example "this will cost $100". A responds that it does not agree to the condition. B then sends another constraint message saying "ok, we'll do it for $50".
   • Use Case 7.23: Choice. B sends a (must respond) constraint for example ""I can process this in 3 hours but it will cost you and additional $100; otherwise it will take 12 hours". A selects one of the two choices.
   • Use Case 7.24: Counter proposal. B sends a (must respond) Constraint message: "processing will take 2 days". A does not accept the constraint, and instead offers a counter-proposal, for example, "process it in 1 day and I'll pay an additional $100".
     
     
8. Conversation
   
   
   • Use Case 8.1: In-band conversation. A sends a miscellaneous message to B, in the context of a particular transaction, for example A might say "thank you" to B.
     
   • Use Case 8.2: Out-of-band conversation. A and B carry on a conversation, not pertaining to any particular question. For example B might say to A "it's only the 3rd of the month and you've already used 80% of your months quota". A may respond "Who's asking all the questions?" Etc. They may carry on a conversation, all within a single transaction.
     
   • Use Case 8.3: Conversation to begin Transaction. A and B carry out a transaction using connection-oriented communication between operators (sometimes referred to as "synchronous" communication, as in Chat). The transaction begins with a conversation sequence, for example A says "Hi, how are you? I'd like to ask a question".
   
   
9. Question Acknowledgement
   • Use Case 9.1: Unsolicited acknowlegement. B receives a question and realize it will be a long time before any part of the answer will be available, so it sends a message immediately, effectively acknowledging the question (perhaps including some time estimate).
   • Use Case 9.2: Automatic message. The operator at B has left the system unattended (for example has gone on vacation) and has put B in auto-response mode. B receives a question and automatically sends an acknowledgement with a message to the effect that B is currently unattended, including a time estimate when it will again be attended.
   
   Note: although these previous two cases represent two different functional scenarios, it is not anticipated that they will result in different protocol behavior.
   • Use Case 9.3: Separately Solicited Acknowledgement. A sends a question and recieves no response for a long time, so requests an acknowledgement, which B sends.
   • Use Case 9.4: Accompanying Solicitation of Acknowledgement. A sends a question, which includes an accompanying request for immediate acknowledgement, which B sends.
     
     
     
10. Reply to Patron
    
    
    • Use case 10.1: Successful reply to patron. A sends a question to B and asks that B reply directly to the patron (not via the protocol), rather than reply to A (via the protocol). B replies directly to the patron.
      
    • Use case 10.2: Unable, process via protocol. Similarly A asks that B reply directly to the patron . But B is unable to reply directly to the patron, so continues to processes the question via the protocol.
    • Use case 10.3:Unable, what now? B sends a constraint "unable to reply directly to parton. Continue?"
    • Use case 10.4: Unable, so terminates. Similarly, B is unable to reply directly to the patron, so B terminates the transaction.
    • Use case 10.5:Partial reply to patron. B is able to reply to the patron for one part of the answer (e.g., a free part-answer) but must place constraints on another part (e.g.,where there is a fee). So B answers the first part directly to the patron but send the second part to A via the protocol.
      
11. Patron Redirect
    
    
    • Use Case 11.1: Successful patron redirect. A sends a message to B (including the session log and information about the user) requesting that B take responsibility for answering the user's question. B sends back to A contact information by which the user will be able to initiate a new session with someone at B and continue asking the question. A sends the information to the user, who then initiates a new session with someone at B, who answers the question.
    • Use Case 11.2: Redirect discarded. Same as above, except that the user never contacts B. Eventually, B discards the information it has gotten from A.
    • Use Case 11.3: Double redirect. After hearing from the user, B chooses not to answer the question either and directs the user to initiate a session with C.
    • Use Case 11.4: Server-initiated redirect. A sends a question to B who requests A to tell the user to contact them which the user does. B provides the answer to the user. B then notifies A that the question was answered, possibly including a copy of the session transcript containing the answer.
      
12. Forwarding
    
    
    
    • Use Case 12.1: Successful forwarding scenario.A sends a question to B who initiates a second transaction with C, sends ("forwards") the question to C, asking if C will take responsibility for answering it. C responds affirmatively to B (ending the second transaction) who informs A (ending the first transaction). A then initiates a third transaction, with C, who processes the question and provides the answer to A.
    • Use Case 12.2: A never contacts C. Similarly C accepts the forwarded question and awaits initiation of a transaction from A. But A never contacts C, so eventually C discards the question.
      
    • Use Case 12.3: Leftover parts discarded.B has received one or more question parts from A, and, as it is B's intention to forward the question, it first waits for the entire question (it waits until it receives a question part indicating "last part") and then sends the entire question (all received parts consolidated into a single part) to C as a Question message. However, B then subsequently receives additional question parts. It discards them, or it may hold them (in case the forwarded request is rejected), however it does not forward the additional parts.
    • Use Case 12.4: Leftover parts retained. Similarly B has forwarded a question and then subsequently receives additional question parts. B holds them, just in case the forwarded request is rejected.
      
    • Use Case 12.6: Forward rejected: A sends a question to B who forwards it to C who rejects the forwarded question and so notifies B, who notifies A.
      
    • Use Case 12.7: Forward rejected so B answers. Similarly C rejects the forwarded question and notifies B. So B answers the question.
      
    • Use Case 12.8: Forward rejected but C answers. Similarly C rejects the forwarded question, however, C supplies the answer instead (to B) who supplies it to A.
      
    • Use Case 12.9: Forward accepted but C answers. C accepts the forwarded question, however, C supplies the answer in the response to B, saying in effect "I'll accept this forwarded question and will accept a transaction from A, but here's the answer; why don't you give it to A and A can contact me if it needs more information".
      
    • Use Case 12.10: Forwarded constraints. B forwards a question to C and includes all applicable constraints (i.e. it omits constraints that A might have imposed that pertain only to the transaction between A and B). However these are included only for the purpose of helping C to make an informed decision about whether to accept the question. A does not assume that C has accepted any constraints; thus when A subsequently contacts C it again states any applicable constraints.
      
13. Multiple Questions
    
    
    • Use case 13.1: Distributed Questioning. A sends a question to B who breaks it into parts and forwards them to other systems (acting as a client), awaits and consolidates answers, and sends a single answer to A.
    • Use Case 13.2: Multicast. A sends a question to B, who (acting as a client) sends the question to several servers, consolidates the answers into a single answer and responds to A.
      The different servers may specialize in different aspects of the answer, or they may offer different points of view, or even give different of conflicting answers and it is possible, perhaps likely, that human/intellectual effort will be required to consolidate the answers.
    • Use Case 13.3: Multiple Asynchronous Questions. A sends a question to B and while awaiting a response, initiates a second transaction with B and sends a second question (unrelated to the first) over the second transaction. A sends additional question parts for the first question interleaved with additional question parts for the second. These are distinguished because each question part is associated with the proper transaction. Similarly, B sends answer parts for both questions (asynchronously) which are also correctly associated with the proper transaction.
      
14. Topological Scenarios
    
    
    • Use Case 14.1: Referral. A sends a question to B who decides that C is the more appropriate system to answer it. B responds to A recommending that it send the question instead to C.
    • Use Case 14.2: Chaining. A sends a question to B who decides that C is the more appropriate system to answer it. B sends the question to C, who supplies the answer to B, who supplies the answer to A.

      Chaining may be necessary for political reasons: Suppose A is a consortium member and B is the consortial-contact for outside-consortium information services (an arrangement in place for efficiency and budgetary reasons); A may be intentionally isolated from C because B is the only access point, and controls expenditures on external information services. There may be commercial reasons for chaining: A may have contracted B to provide information services; A might do this for efficiency and budgetary control while B does it for the revenue -- A does not want the expense and uncertainty of dealing with parties other than B, while B does not want A have a direct relationship with B's sources.

    • Use Case 14.3: Gateway. A and B communicate via QATP but C does not support the protocol, it communicates by phone and free-text email. A is not interested in communicating in any manner other than the protocol, B is more flexible and supports both protocol and non-protocol communication. So A cannot communicate directly with C and utilizes B as an intermediary.
      

      This is a common situation during the adoption period of a new protocol when normal business goes in part through the new protocol and in part around it. The intermediary in such a situation plays a crucial role, translating messages from one supported format (what A understands) to another (what C understands). It will need to be involved in every message that crosses the protocol/non-protocol boundary (though it might have no active role) and have some representation in its database of each transaction including explicit naming of who is on each end of the transaction, so it can match up partners appropriately and send the messages to the correct party.

15. Reference to Archived Transaction

    In each of these cases, A sends a question and includes a reference to an archived (closed) transaction.

    • Use Case 15.1: B finds the archived transaction and uses it to help process the current question.
    • Use Case 15.2: B cannot find the archived transaction (or otherwise cannot or does not wish to use it). B sends a Constraint message to A saying "cannot find the referenced transaction". So A cancels the current transaction.
    • Use Case 15.3: B responds with a constraint: "cannot find the referenced transaction". So A tell B to process the question anyway (without the benefit of the information that might have been available in the archived transaction).
    • Use Case 15.4: As above B tells A that it cannot find or otherwise cannot use the referenced transaction. So A (who has archived the transaction) sends B the archived transaction (or the relevant content from the archived transaction), and B proceeds to process the question.
      
      
16. Timers
    • Use Case 16.1: Timeout. A sends a question and says "if I don't hear from you (receive either an answer, acknowledgement, request for clarification, constraint, etc.), in one hour, I'll timeout the transaction". B does not not respond in an hour so A closes the transaction.
    • Use Case 16.2: Acknowledgement and Reset. Similarly A sends a question that includes an activity timer. As the timer approaches expiration B doesn't have any relevant message to send, but wants to keep open the transaction. So B sends a question acknowledgement, and A resets the timer.
      Use Case 16.3: Constraint Timeout. B sends a Constraint message that includes an activity timer, saying "if I don't hear from you in 6 hours the transaction will terminate". A fails to respond and B terminates the transaction.
    • Use Case 16.4: Response in time. As above B sends a Constraint message that includes an activity timer, A responds before the timer expires, and the transaction continues.
    • Use Case 16.5: Constraint timer reset request. B sends a Constraint message with an activity timer. As expiration approaches, A is not ready to respond (hasn't contacted the user) so sends a request to reset the timer. Subsequently A responds to the constraing message and the transaction continues.
    • Use Case 16.6: Clarification timer. B sends a request for clarification that includes an activity timer, which says "if I don't receive the requested clarification before the timer expires I'll terminate the trancaction".
    • Use Case 16.7: Awaiting additional Question Part. B sends an Answer part saying "this is the final answer (for now) however, we'll keep the transaction open for an additional hour; if we don't hear from you the transaction will then be closed." A sends another question-part (within the hour) and the transaction continues.
    • Use Case 16.8: Additional question part timer reset. B sends an Answer part as above (tentatively final, but keeping the transaction open for an additional hour). A knows (or thinks) that it needs to send another question part but can't get it formulated within the hour (cannot contact the user). So A requests that B reset the ActivityTimer.