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:
- 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 [email protected]
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
- A transaction may remain open indefinitely; it need never be
closed. Theoretically it can continue forever.
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.
- 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.
- 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
- 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
- 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
- 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.
- 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
- Use Case 5.1: Simple clarification. While
processing a question B determines that clarification
is required, requests and receives clarification from A,
- 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
- 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.
- 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.
This terminology (used in this as well as other sections of
this document) is intended for descriptive purposes only and
has no protocol significance.
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.
- 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.
- Use Case 6.4: Suspend/resume. A requests B to
suspend processing until further notice. Subsequently A requests B to
- 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
- 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.
- 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
- 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
- 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).
- 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.
- 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
- 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
- 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
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).
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).
- 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
- 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
- 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.
- 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".
- 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
- 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.
- 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.
- Use case 10.4: Unable, so terminates. Similarly, B is
unable to reply directly to the patron, so B terminates
- 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.
- 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.
- 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
- 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
- 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.
- 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.
- 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
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.
- 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
- 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.
- 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
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
- 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
- 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.