It's a good start.
The OPES processor should make the decisions about what to send to
the consumer. This might just be a matter of terminology, but the
processor is in control of the source and destination and should not
send messages to new destinations based on OPES server demands.
The start message should identify the total length of the data, if it
is available. This might stretch over several "bids", see below.
The first response from the server should identify the new total length,
if it is available. If the length will change, but the new size is
unknown, the server should indicate this.
There is some confusion about "destination" - the OPES server should
never change the destination (i.e., the endpoint), so I don't see why
it is needed. In the redirection example, it would be sufficient to
change the headers, and the purpose of "destination" is a mystery to
me.
The relationship between the application-layer framing, the bid and
offset, and the OPES framing is not clear from your examples. The
application data may be transmitted to the OPES server a packet at a
time - this will mean a different bid on every data message, if you
literally mean that a bid is a buffer id. Otherwise, it should have
some other name.
Also, the information about a bid should include its total length.
It should be possible to send the start and end messages on a separate
transport connection for handling errors or congestion.
The case discussed for multiple services, multiple responses, should
be included. To support it, one needs multiple service lists and an
id for each response.
It should be possible to indicate that the transmitted data comes
from several places in the bid. This allows the OPES processor to omit
huge cookies and other junk; the response, by including this information,
helps the process limit the state and parsing.
Hilarie