OTS11 — avoiding the register_resource round trip

> 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.