Subject: RE: what-parts-to-send-or-skip

From: "Martin Stecher" <[email-masked]>
Date: Sat, 25 Oct 2003 08:32:37 +0200

Hi Alex,

> 
> > Last-Needed-Part would address this. But maybe we can add anoter
> > parameter "Pause-Offset" to the feature which acts as a data-pause
> > pre-request. It requests a first data-paused message after n bytes
> > of the original body.
> > As with data-pause, OPES processor SHOULD honor this request.
> > This will be similar to the Preview feature of ICAP/1.0.
> 
> Good, except for the Offset part. Since the offset is not known a
> priory, services that need just headers will have to overprovision on
> average but will not get enough sometimes.

I think there is a misunderstanding. I do not mean an offset that counts
from the beginning of the application message but from the beginning of
the body part (request-body in request profile, response-body in response
profile).
Services only interested in headers, can use Pause-Offset: 0.

I see here an advantage for other services too, for example,
a service dealing with GIFs may want not only want to check for the
Content-Type header but also whether data starts with the three bytes "GIF".
It could use Pause-Offset: 3

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 25 Oct 2003 18:06:50 -0600 (MDT)

On Sat, 25 Oct 2003, Martin Stecher wrote:

> I think there is a misunderstanding. I do not mean an offset that
> counts from the beginning of the application message but from the
> beginning of the body part (request-body in request profile,
> response-body in response profile). Services only interested in
> headers, can use Pause-Offset: 0.

Yes, I did misunderstood. What you propose is probably better, at
least as far as HTTP and similar protocols are concerned. I just find
the naming of the parameter misleading. So let's have two parameters:
	Wont-Use-Body: offset
and
	Pause-At-Body: offset
both using offsets from the beginning of a message body. These NR
parameters are semantically equivalent to Wont-Use parameter and
Data-Pause message already documented in OCP Core (and you should
refer to that documentation from the HTTP draft as much as possible
instead of repeating it, IMO).

From processor implementation point of view, the above parameters
become meaningful when the size of headers is known. At that time, the
processor should behave as if it received a corresponding Wont-Use
parameter and/or Data-Pause message.

Alex.

---

From: "Martin Stecher" <[email-masked]>
Date: Sun, 26 Oct 2003 21:29:26 +0100

> instead of repeating it, IMO).

Agreed.

> parameter and/or Data-Pause message.

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 that is sent at the very beginning of the application message
to indicate that it will not send a DUY message for the first n bytes.
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.

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 26 Oct 2003 14:59:42 -0700 (MST)

On Sun, 26 Oct 2003, Martin Stecher wrote:

> 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

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?

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.

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.

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

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

While services that rewrite content in a significant way would use
	Wont-Send 2147483647
OCP message or Wont-Send-Body NR parameter.

Alex.

---

From: "Martin Stecher" <[email-masked]>
Date: Sun, 26 Oct 2003 23:41:40 +0100

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

> continue to keep that data.

Yes. It just allows for optimizations but it does not enforce it.

> Wont-Use and add Wont-Look to OCP Core so that you can refer to them

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?

> Wont-Send-Body: 2147483647

Yes!

> 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

---

From: "Martin Stecher" <[email-masked]>
Date: Mon, 27 Oct 2003 00:27:28 +0100

> What is now the Wont-Send OCP message?

Aaah, just found it in your other message (didn't read it before).
I will respond to that mail (Wont-Send message is a good idea).

Martin

---

From: "Martin Stecher" <[email-masked]>
Date: Mon, 27 Oct 2003 01:29:39 +0100

> Wont-Send-Body: 2147483647

It will be

Wont-Look-Body: 0

> all original bytes up to the Wont-Use point. Right?

I described now:
  An OPES processor SHOULD behave as if it receives a Wont-Look
  message at the time that it will have sent the given
  number of OCTETs of the application message body part, for example,
  if the Wont-Look-Body value is zero in an HTTP response profile, the
  OPES processor SHOULD send an AME message with result code 206 after
  sending the response-header message part and before starting with the
  response-body message part.

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 26 Oct 2003 19:46:36 -0700 (MST)

> > Wont-Send-Body: 2147483647

Agreed. Wont-Send offset semantics (will not send anything up to the
specified point) is going to be different from the Wont-Look semantics
(will not look at anything beyond the specified point). Right?

I hope that is OK. If not, we can have more explicit names:

	Wont-Look-Body-After:
	Wont-Send-Body-Before:

or something of that kind.

Alex.