Many OCP messages use identifiers: transaction identifier, application
message identifier, service group identifier. To work, those integer
IDs must be unique within some scope. For example, transaction
identifiers must be unique within an OCP connection while application
message identifiers must be unique within a transaction.
The question is whether object ID uniqueness is preserved and
guaranteed after the corresponding object disappears. For example, can
an agent reuse transaction ID on the same connection once the old
transaction is over?
A simple answer would be that IDs must not be reused within a given
scope, ever. That is, the "scope" is defined as a "lifetime" rather
than "at any given time" instance. For example, a transaction ID must
be unique across all transactions ever present within an OCP
connection. This rule is convenient: Agents can use IDs to log events
and cross-reference different logs without much work. However, to
enforce this rule, a receiving agent would have to remember all IDs it
has seen. That is too much overhead, of course. Thus, if we follow
this "convenient" path, we are likely to end up with undetected
violations that will hinder interoperability.
Another simple answer would be that object IDs can be reused after
object death. That is, the "scope" is defined as a "at any given time"
instance or a snapshot rather than a "lifetime". For example, a
transaction ID can be reused once the old transaction is closed. This
rule does not allow for effortless logging and cross-correlation. An
agent would have to maintain its own map of IDs if the agent wants
long-term uniqueness.
The last option is to prohibit object ID reuse _and_ prohibit ID value
decrease. The latter artificial restriction would make it cheap to
check for violations at the recipient: if a supposedly new ID is
smaller than the last identifier seen, it is not really new and must
be rejected. Generating IDs is as easy as it is with the first option.
This rule assumes that OCP messages introducing new identifiers are
received in the order they were sent, which seems to be the case.
I intend to document the last option unless you have better ideas or
objections.
Thank you,
Alex.