Legacy Issue Number: 3748
Source: Hewlett-Packard ( Peter Furniss)
> One possible use for the implementation data would be to avoid the
> additional round-trip of register_resource from an interposing
> sub-coordinator. This involves putting the subordinate reference (as a
> Resource) in the context on the response. However, that is not enough
> because the RecoveryCoordinator reference from the superior (usually
> returned on register_resource) is unique to the Resource. However, if it is
> possible for the superior to pre-construct a RecoveryCoordinator reference,
> this can be put in the context on the request. (Obviously, not all
> implementations will be able to do the pre-construction, but some will, and,
> when working homogeneously, gain the advantages of interposition without the
> cost of the extra round trip).
> The RecovCoordinate reference would only be a "potential" reference,
> becoming real if and only if the response context included a Resource
> reference - receipt of that Resource reference requiring an immediate
> (locally-handled) registration.
> Two possible changes arise:
> 1) If this is done, it is vital that an implementation that does not
> understand this discards the implementation-specific data (contra the
> resolution of 3593)
> 2) Alternatively this could be done in a separate, defined service context.
> The semantics can be tied down precisely and allow avoidance of the
> round-trip even on interoperation.
Reported: OTS 1.0b1 — Tue, 18 Jul 2000 04:00 GMT
Updated: Fri, 6 Mar 2015 20:57 GMT