ietf-openproxy
[Top] [All Lists]

Re: capability negotiations

2003-10-06 13:08:33

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



<Prev in Thread] Current Thread [Next in Thread>