Hi Alex,
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?
Yes, thank you very much for clarification. As many others I best grap things
with real examples ;-)
From your last message I thought about a combined algorithm-keysize value and
so didn't get the point
The simple header "Encryption: (RSA-512, DES-1024)" works of course.
I hear you saying (and agree) that assembling of such a value is not an OCP
standard thing; so why introducing such misfitting element if the same can be
expressed with an OCP standard structure. You are right.
The only answer could be "because humans find it easier to read", but since OCP
is usally handled by a machine... ;-)
When using the structures for NO messages, we need to make sure that we have
also such a more complicated example in the specs. Otherwise I am afraid that
programers oversee this point and implement something that only works for lists
with a single element which probably often works but will break general
interoperability.
[...]
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?
I think (a) is a little more complicated. You cannot stop with the first
matching feature, you have to continue and see whether an even better match
will be found. In the example above RSAx512 may work but DESx1024 may be
preferred.
But I agree that the software can handle this and it is not hard to program.
[...]
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?
Again, thank you for the many examples. They really helped me.
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.
When also giving a more complicated example in the specs, I guess that we can
achieve powerful, flexible and interoperable OCP implementations.
So, yes, you convinced me. Let's do it this way.
Will you add the named structure member concept to the OCP core?
I could then describe the feature negotiation in the HTTP draft, if you like.
Are you ok with the suggested member names?
Optional-Parts, Skip-Parts, Transfer-Encodings, Content-Encodings
We also now have a good start for connection encryption negotiation, I guess :-)
Best regards
Martin