I think you've raised two important design questions that must
be addressed explicitly, possibly in OCP Core (in part).
(1) We need to be more clear what is being adapted, what is
being supplied for information purposes only, what is being skipped,
what is potentially stale and must be checked by processor (and when
the checks are made).
Yes.
(2) We need a "content" size prediction for performance
reasons, but we do not have a definition of "content", only data.
Sizep seems to be useless. A new parameter, tied to the "content"
definition is needed. "Content" definition should probably be
application-specific and negotiable.
I agree.
...
Putting all this together, I feel that using the sizep parameter for
Content-Length indication does not really work.
I agree.
Shouldn't we better introduce a Content-Length named parameter to
AMS messages that does what we really want: Promise a length that
can be used for HTTP Content-Length header correction?
Does sizep have any useful purpose at the lower (application data)
level it is being used right now? Should we delete sizep from the Core
and add AM-CLP parameter instead (application message content length
prediction)?
Yes, we should add AM-CLP.
For the HTTP request profile this is the predicted length of the request-body
message part.
For the HTTP response profile this is the predicted length of the response-body
message part.
Correct?
I suggest that the AM-CLP is not decreased from DUM to DUM message such as
sizep.
Is it suitable to make it a parameter of the AMS message and not of DUM
messages?
Is there then a useful purpose of sizep? I am not sure. I tend to agree that
AM-CLP could
replace sizep. The only purpose I can think of is to allow the peer to prepare
some buffer
size for all application data. I don't think that this will be necessary for
HTTP adaption
but it may make sense for other application bindings. Maybe we just leave sizep
in. If it
does not help, it does not hurt either as an optional parameter. What do you
think?
Martin