Subject: Re: capability negotiations

From: Alex Rousskov <[email-masked]>
Date: Mon, 6 Oct 2003 14:08:33 -0600 (MDT)

Martin,

	I like simplifications and understand what you are trying to
do. I agree that there is a complexity problem here. I think your
solution works OK on a local level. I am, however, concerned about
overall consistency and symmetry of protocol mechanisms. Let me try to
explain with a couple of examples and observations.

	You propose to use Optional-Parts, Skip-Parts using named
headers as opposed to [named] feature parameters. Once we separate a
feature ID and its parameters, how will agents report their [multiple]
capabilities in a [single] "I Support" (i-can) response?

	For example, consider a callout service that wants to always
receive request-headers in RESPMOD mode and wants to receive
request-body in RESPMOD mode if and only if that body is chunked. You
cannot express that condition using a single feature structure or a
single feature ID with attached named parameters. You need two
structures OR two messages each with its own group of named
parameters.

	Do you think that the above scenario is too esoteric to
support?

	When negotiating/announcing encryption, would not the same
problem arise? How to express "RSA with 512bit keys" and "DES with
1024bit keys" in a single NO or i-can message?

	Will we never need to offer two features at once?

	Do we want to eliminate i-can mechanism altogether?

	Once we start using named parameters for features, we cannot
describe multiple conflicting features within one OCP message. A
general solution is a list of structures (with [named] members).  I
would even argue that we can make everything symmetric if named
members are using name:value MIME syntax OR if named parameters adopt
a name=value non-MIME syntax instead.

	This generalization allows us to, essentially, list OCP
statements/messages (such as negotiation offers or i-can responses) in
a single OCP message:

	NO ({
		"feature-id1"
		param1: value1a
		param2: value2a
	},{
		"feature-id1"
		param1: value1b
		param2: value2b
	})
	Applies-to-whole-message-name1: value1
	Applies-to-whole-message-name2: value2
	...

where "Applies-to-whole-message-name" stands for a property that
applies to the whole NO message and not any feature being negotiated
in particular. SG, for example, is one of such named parameters.

As you can see, this leads to a very symmetric/consistent syntax
because the whole message prefix becomes nothing but an OCP structure
(just without the surrounding {} which perhaps should be added)! This
simplifies parsing and internal representation, IMO: the same
code/structures are used to store and manage whole messages and
message parts.

We are now kind of stuck in the middle: we have structures but we are
afraid of them. This is probably the worst position to be in!

I like symmetry and consistency. The idealist in me says "a feature
should be a structure OR we should not have structures at all". Or, in
other words, "either we commit to support structures in any context or
we do not support them at all".

Do you see what I am getting at? Would you prefer to get rid of
structures completely OR use them extensively? Do you see any other
consistent design options?

Thanks,

Alex.

On Mon, 29 Sep 2003, Martin Stecher wrote:

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