Subject: capability negotiations

From: "Martin Stecher" <[email-masked]>
Date: Mon, 29 Sep 2003 11:26:36 +0200

Hi,

here are some thoughts about the capability negotiations.

Current status:
HTTP/OCP uses NO and NR messages to negotiate one of the two defined application profiles (request or response) plus optional message parts.
Futher information exchange about capabilities for transfer- and content-encodings needs to be defined and done.

Question:
Can we simplify the application profiles negotiation and how to implement the encodings stuff?

Compare with ICAP/1.0:
ICAP defines the OPTIONS method; in a response to an OPTIONS request, the ICAP server returns various information, including support for the main methods (REQMOD/RESPMOD). But which method to use is not negotiated and ICAP does not know something about optional message parts, skipped parts or information about supported encodings.
If to be implemented it would probably be done in the OPTIONS request.

Do we really need to negotiate the HTTP profile?
Depending on the vectoring point, an OPES processor will either send a HTTP request or an HTTP response via OCP to the callout server. It makes not much sense to offer both profiles and let the callout server select.
All ICAP implementations I know and the rules language show: The decision which profile to use is being done in the OPES processor.
Still the information whether a callout server at all supports this profile is important; but it could be done in a "has feature" message, rather than in the negotiation offer.
So, I vote for restricting the NO message to send a single application profile, not a list of profiles.
The callout server can then either accept or decline.
Having a list of profiles can make the negotiation offer very long if additional parameters are offered as an option. In the current draft we offer additional message parts as options and adding more paramters would make this much too long.

Other parameters
Client and server need to exchange information about (or negotiate on):
  1. wanted additional optional message parts 
       server asks client
       e.g. please add original HTTP request headers to HTTP response)
  2. standard message parts not needed
       server tells client
       e.g. do not need long HTTP request body, only interested in headers
  3. supported transfer encodings (or HTTP version)
       client and server need to tell each other
       e.g. is it ok for the server to add chunked transfer encoding?
  4. supported content encodings
       client and server need to tell each other
       e.g. does the client need to decode gzip encoding before sending message to server?
  5. maybe additional parameters, specific for the callout server
       e.g. number of parallel connections supported
  6. maybe additional parameters, specific to the service to use
       e.g. please add more meta information such as user info

I think it is not a good idea to create separate messages (negotiation offer or has-feature) for each parameter although several messages could be sent in a single TCP frame.

So, what about adding these paramters as named parameters to the NO and NR messages. If the NO message has only a single application profile it works that way.

Example:
  NO "38:http://iana.org/opes/ocp/HTTP/response"
  SG: 10
  Optional-Parts: request-header, request-body
  Transfer-Encodings: chunked
  Content-Encodings: gzip, compress
  
  NR "38:http://iana.org/opes/ocp/HTTP/response"
  SG: 10
  Optional-Parts: request-header
  Skip-Parts: response-body
  Transfer-Encodings: chunked

It means:
  Client wants to do response modification with services in group ten.
  It offers two additional optional message parts.
  Client supported chunked transfer encoding and gzip and compress content encoding
  Server confirms that it can do response modification and asks for the request-header as an optional message part.
  If the client is able skip the response body part, it may do so.
  Chunked transfer encoding is also supported by the server but if the message has a content encoding, the client has either to decode it or the server won't understand it (not a problem in this example because Skip-Parts header indicates that it does not need the body at all.

What do you think about this? Can we do it that way?

Regards
Martin