ietf-openproxy
[Top] [All Lists]

RE: capability negotiations

2003-10-07 07:14:02


On Tue, 7 Oct 2003, Martin Stecher wrote:
The good thing is that many real-world examples will probably just
have a single feature in the list and the list of structures does
then look still easy enough for a human being to understand.

Agreed.

When also giving a more complicated example in the specs, I guess
that we can achieve powerful, flexible and interoperable OCP
implementations.

One could only hope.

Will you add the named structure member concept to the OCP core?

Yes, with the next revision, probably this week.

Named members will use the same syntax as named parameters to keep the
grammar simple. I will need to think about end-of-member delimiters
though. I will try to convince myself that we should always use CRLF,
but I am not sure yet. The subgoal is for any OCP message to be a
valid OCP structure so that parsing, storing, and managing a message
would be the same as parsing, storing, and managing any complete part
of a message, just like it is with XML.

I could then describe the feature negotiation in the HTTP draft, if
you like.

Please do.

Are you ok with the suggested member names?
  Optional-Parts, Skip-Parts, Transfer-Encodings, Content-Encodings

Do we assume that these negotiations will happen infrequently in most
cases (because negotiated service group will be reused for many
transactions)? If yes, then I have no problems with the above names.
If we assume rather frequent negotiations, I would suggest
abbreviating the above: PO, PS, ET, EC.

We also now have a good start for connection encryption negotiation,
I guess :-)

Yes, that's another big pending chunk of work. Once you are done with
HTTP negotiations we can solicit help with connection encryption
negotiation, using your text as an example.

Thank you,

Alex.


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