That seems to work for the Pause-At-Body parameter but makes less
sense for Wont-Use-Body. This parameter is not like a DUY/DUM
message that comes with Won-Use after the n bytes of a body but can
be seen as a DUM message with empty payload but Wont-Use parameter
Agreed up to this point.
that is sent at the very beginning of the application message
I would think it can be sent only after the original headers were sent
so that header size is known.
to indicate that it will not send a DUY message for the first n
bytes.
and here we have a problem:
I thought that Wont-Use in NR indicates that the server does not want
to see those body bytes at all! Otherwise, it should use Pause-After.
Not only Wont-Use tells the processor that preserving those bytes for
this service is a waste, but that _sending_ those bytes is a waste.
The processor SHOULD terminate the message with AME/206 after sending
all original bytes up to the Wont-Use point. Right?
Great,
you had one feature in mind but the name and the "does the same as the
corresponding name of the core" brought me to create a different feature ;-)
It's also nice, because it could allow for preservation commitment
optimization.
In other words, does "will not use" mean "will not even look at" OR
"will not send back as-is"?
Hmm... I think it means the former when sent as a part of a NR
response (a Wont-Use-Body parameter) and it means the latter when sent
as a part of a Wont-Use message! That's bad. We should rename. How
about:
Wont-Send (to stop preservation commitment, former Wont-Use)
Wont-Look (to stop original data flow)
I would propose to call the first one "Dont-Keep" but I prefer to
state the sending agent state/decision rather than instruct the other
agent on want to do. There may be external reasons for processor to
continue to keep that data.
Yes. It just allows for optimizations but it does not enforce it.
Do you agree that we need one semantics for NR and another for
preservation commitment management? If you do, I would rename
Wont-Use and add Wont-Look to OCP Core so that you can refer to them
from the HTTP draft.
It's not yet too late to do these changes ;-)
Wont-Use will become Wont-Send
and
Wont-Look will be new.
BTW: Can I make a XML xref to the section in core (without hard coding the
section number) so that possible changes in ordering are reflected?
It does not terminate the preservation commitment, but it tells the
OPES processor that it does not need to preserve the first n bytes
of the message. I expect to see only one value in real life:
Wont-Use-Body: 2147483647
to indicate that the callout service will never send DUY messages.
But maybe other scenarios can be found.
I think the most common scenario for URL blocking services would be
to send (in NR)
Wont-Look-Body: 2147483647
rather than
Wont-Send-Body: 2147483647
Yes!
While services that rewrite content in a significant way would use
Wont-Send 2147483647
OCP message or Wont-Send-Body NR parameter.
What is now the Wont-Send OCP message?
You mean Wont-Send parameter in DUM message, right?
Regards
Martin