Discussed in 2006-10-24 telecon:

Parameter should be named "TimeoutHint" (milliseconds duration)

if server detects the timeout the service returns the BAD_TIMEOUT error code (already defined)

Adding a timeout parameter is easy. However, there is behavior associated with this parameter that has to be described. E.g.,:

• relative or absolute timeout
  relative - if server takes 2X the timout server can be sure the client is gone

• can server ignore it
  yes

• what if data are immediately available but the request is already timed out when arriving in the server
  server can ignore the timeout

• correlation between timeout parameter in stack and timeout in stack API (recommended tolerance)
  Client sets the timeout on a per-call basis

• profilable feature? It is extra work - why bother if every request can immediately be fulfilled (in a device)
  server can ignore

• is all of this in Part 4 or some text also in Part 6 (does the stack on client-side handle the timeout?)
  new text for both part 4 and part 6

Randy and Mathias will updated versions of Part 4 and 6 for review at the Cleveland meeting next month.

Fixed in document
OPC UA Part 4 - Services 1.01 Specification_V1.doc

Added the following parameter to RequestHeader:
Name: timeoutHint
Type: Duration
Description:
This timeout is used in the Client side Communication Stack to set the timeout on a per-call base.
For a Server this timeout is only a hint and can be used to cancel long running operations to free resources. If the Server detects a timeout, he can cancel the operation by sending the Service result Bad_Timeout. The Server should wait two times the timeout after he received the request before cancelling the operation.

Reviewed changes in a telecon prior to 2006-12-12