On Tue, 3 Jun 2003, Graham Klyne wrote:
I don't know if it helps, but some similar issues to those you
mention were addressed in the content negotiation work I did a while
back (RFC2533).
Thanks for the pointer! It looks like your RFC may be very useful to
OCP implementors, especially if we decide to support complex feature
expressions like "(A2 and (B1 or B2)) or (A1 and B1)" as opposed to
simple (but, as you note, potentially very long) "normal" AND/OR
lists. My undestanding is that RFC 2533 outlines a way to
pragmatically match [complex] feature expressions in negotiation
offers with available/desired capabilities, also a [complex] feature
expression. A how-to document replacing a dry book on boolean algebra,
sort of.
My current intention is to use very simple expressions. I convinced
myself that it is the right starting point after looking at what
negotiation mechanisms are offered by a few existing protocols that
are somewhat similar to OCP (BEEP, PPP, IKE*, etc). I did not find
anything that supports negotiation using really complicated feature
expressions. Yet, these protocols "work". Thus, I decided it would be
OK to start with something simple and extend the interface only of
actual need is detected.
I also agree that ordering dependency may lead to suboptimal
negotiations. However, again, it looks like our environment is simple
and structured enough to marginalize that risk.
Your application domain is probably different -- it already has a
pressing need for complicated content descriptions.
Thank you,
Alex.
P.S. RFC 2533 is the first RFC I have seen that mentions Prolog,
nice work!