On Mon, 6 Oct 2003, Martin Stecher wrote:
On the other hand I am concerned about negotiation complexity. I
think that it is unlikely that two agents find a perfect match or
the nearly perfect second choice even if you list all features in a
complicated decision matrix. Agents need to workaround lacks of
capabilities of the other side and so they could work around a
slightly restricted negotiation procedure.
This is my concern as well. Perhaps we can address both concerns
(clean design and negotiation complexity) without too many sacrifices.
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?
I do not think that encryption is transaction dependend, it works on
connections.
Yes, I was using connection encryption to provide a better example.
But it makes no difference since negotiation _mechanisms_ for
connection- and transaction-scope should be the same, right?
Certainly an agent can respond to a "which encryption method do you
support" with a list of encryptions in an i-can message.
Unless I am missing something, using your simplified format, the agent
will _not_ be able to offer the above choices in NO and will not be
able to respond with them in an i-can response. Given your single
feature option, an agent can only say:
NO "opes:connection-encryption"
Algorithms: (RSA)
Key-Sizes: (512);
or
NO "opes:connection-encryption"
Algorithms: (DES)
Key-Sizes: (1024)
The agent cannot say:
NO "opes:connection-encryption"
Algorithms: (RSA,DES)
Key-Sizes: (512,1024)
because the agent does not offer/support RSA with 1024bit keys and DES
with 512bit keys. With current, more complex scheme, the agent can
express both options (I will use named members):
NO ({
"opes:connection-encryption"
Algorithms: (RSA)
Key-Sizes: (512)
},{
"opes:connection-encryption"
Algorithms: (DES)
Key-Sizes: (1024)
})
SG: 10
;
And the recipient can make a choice knowing all available options
(there are two options available in this example). Do you see what I
am getting at?
All of the above applies to i-can responses as well, of course: Only
lists of structures can express RSAx512 and DESx1024 ability without
implying RSAx1024 and DESx512 support.
Even if it was a feature of an NO message, the value of the named
parameter could be a list of course, such as my example
Optional-Parts: request-header, request-body
which should better read
Optional-Parts: (request-header, request-body)
to be consistent and symetric, sorry for that mistake.
Of course. That's the way I interpreted it. The problem is that name
parameter lists create a full mesh of choices and do not allow for
specific subsets (see example above). The lists should still be
allowed. The above example can be extended to show a more powerful DES
implementation:
NO ({
"opes:connection-encryption"
Algorithms: (RSA)
Key-Sizes: (512)
},{
"opes:connection-encryption"
Algorithms: (DES)
Key-Sizes: (1024,2048,8192)
})
SG: 10
;
I think usage of named items (either parameters or members of
structures) is the key.
Whether structures are needed for (some) features depends on the
complexity we believe is necessary for a powerful protocol vs. the
complexity that makes the protocol hard to handle (for a human
being).
Exactly. It seems that the final decision depends on whether we think
that supplying more than one feature in a NO and responding with more
than one feature in i-can is essential to support. If the answer is
"yes", then we should support the lists of structures in NO messages.
If the answer is "no, not essential". Then we can limit NO messages to
a single feature (with a full mesh of named parameters). Do you agree
that this is the choice we face?
Did the examples above convince you that we need to support multiple
features in some negotiations?
Also, let's compare the complexity of the two approaches:
a) Multiple structures with named members. A minimal
implementation would require parsing each structure,
checking whether the feature matches capabilities,
until the first matching feature is found.
b) Single feature with named parameters. A minimal
implementation would require parsing the message
headers and checking whether the feature matches
capabilities
So the only difference is in the extra iteration in case (a). Is this
the added complexity you are concerned with? Or did I miss any other
complications?
It is great to have structures. Structures with named members are
even better. But that does not imply automatically that structures
need to be used everywhere, IMO.
True. They only need to be used where the information cannot be
represented using simpler elements. I do not think we disagree on
whether or how to use structures. I think the only thing we need to
agree on is whether we need multiple non-meshed features in a single
negotiation offer or i-can response.
I assume that you then also like to continue support for multiple
application profile features in NR messages?
Not necessarily. Again, I like your simplification. I just want to
make sure it is still general _enough_ :-).
For my full understanding, could you please write the structured
NO/NR messages for my specific example that I gave in the previous
message;
This dialog:
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
becomes this:
NO ({
"38:http://iana.org/opes/ocp/HTTP/response";
Optional-Parts: (request-header,request-body)
Transfer-Encodings: (chunked)
Content-Encodings: (gzip, compress)
})
SG: 10
NR {
"38:http://iana.org/opes/ocp/HTTP/response";
Optional-Parts: (request-header)
Skip-Parts: (response-body)
Transfer-Encodings: (chunked)
}
SG: 10
That is, one feature offered (but there could have been more) and one
more specific feature is accepted (there could not have been more than
one).
message; and also how it will look like when adding the esoteric
condition you suggested?
Well, now you are pushing it! :-)
i-can ({
"38:http://iana.org/opes/ocp/HTTP/response";
Optional-Parts: (request-header)
},{
"38:http://iana.org/opes/ocp/HTTP/response";
Optional-Parts: (request-header,request-body)
Transfer-Encodings: (chunked)
})
See also encryption negotiation examples above.
Again, there seems to be only one important choice here: multiple
structures versus one; all in the context of negotiations and
capability reporting. Did more examples and clarifications change your
preferences in any way?
Thank you,
Alex.