Subject: RE: capability negotiations

From: "Martin Stecher" <[email-masked]>
Date: Tue, 7 Oct 2003 12:08:33 +0200

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

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 7 Oct 2003 08:14:01 -0600 (MDT)

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

Please do.

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

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.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 7 Oct 2003 17:56:33 -0600 (MDT)

> Yes, with the next revision, probably this week.

Done. See the latest snapshot at
http://www.measurement-factory.com/tmp/opes/

Essentially, only the "structure" definition was changed from

  structure = "{" [ value *(SP  value) ] "}" ; spaced values

to

  structure = "{" parameters "}"             ; a.k.a structure members

where

  parameters = [anonym-parameters] [named-parameters]

Alex.