HTTP Adaptation draft defines auxiliary parts. They are used to
deliver an HTTP request to the service that adapts an HTTP response.
Auxiliary parts are not meant to be adapted, of course (it is too
late, the request has already been sent). Yet, they use the same
original dataflow.
OCP Core defines several mechanisms that allow OCP agents to
manipulate original dataflow. Original data can be preserved and
reused by the processor at the server request. Original dataflow can
be paused and resumed by OPES processor at the service request.
Finally, a callout server may get out of the loop and instruct the
OPES processor to send all original data on the server behalf.
It is not clear from the current HTTP draft whether all, none, or some
original dataflow mechanisms apply to auxiliary parts. It seems to me
that data preservation and getting out of the loop is usually useless
when it comes to auxiliary data. However, a low-level pause/resume
features can be useful.
Moreover, I am not sure it would be clear to implementers whether all
OCP Core offsets start with auxiliary data or adaptable data. From
Core point of view, they start with auxiliary data because it was sent
first.
Should we add specific rules that clarify the above? Or should we just
say that from OCP point of view "auxiliary data" is "data" and all
Core mechanisms apply "as is"? If we use the former approach, it is
not clear what Core mechanisms need to be included in this
clarification. If we use the latter approach, it is not clear what to
do when a callout server decides to adapt auxiliary parts.
My current preference is to say that from OCP point of view "auxiliary
data" is "data" and absolutely all Core mechanisms apply "as is". And
then add that the OPES processor MAY terminate a transaction if
adapted flow includes an auxiliary part. The latter can be determined
by looking at AM-Parts parameter of the adapted DU* message.
Comments?
Alex.