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).
One of my goals was to avoid the kind of ordering-dependency you describe
for PPP -- in my view, although that makes implementation easier, it also
increases the scope for unintended outcomes. But, then, the RFC2533
algorithm doesn't really provide for selecting a preferred feature among
available alternatives, even though the format used has a rudimentary
mechanism to express such preferences. There are some theoretical problems
in doing this in a completely general fashion.
FWIW, there's also an implementation, in Java, of the RFC2533 algorithm
available at:
http://www.ninebynine.org/Software/Intro.html#RFC2533FeatureSetMatching
to demonstrate that the RFC2533 matching algorithm is reasonably realizable.
One of the things I noticed when playing with the algorithm, which involves
automatically converting the feature expression to "disjunctive normal
form", is that one can easily end up with long lists of ANDed
conditions. Similar applies to "conjunctive normal form", where one ends
up with long lists of ORed conditions. But at least, using this kind of
framework, one isn't forced to actually *transmit* these long lists.
#g
--
At 12:39 02/06/03 -0600, Alex Rousskov wrote:
On Thu, 17 Apr 2003, The Purple Streak, Hilarie Orman wrote:
> PPP, IPSec and IKE use "offer, select". The trick is to spell out
> the complete set of selections at offer time. Don't say (A1 or A2)
> and (B1 or B2) if (A1 and B2) is not permitted - say instead
>
> { A2 and (B1 or B2) } or { A1 and B1}
I am adding negotiation mechanisms to the OCP draft. While describing
how negotiation works, I realized that providing a _complete_
selection "menu" in one offer would require very deep nesting of OCP
data structures or very long OR lists for some negotiations. I was
surprised that a protocol like PPP (RFC 1661) could handle that
(something the above examples imply) and read the PPP specs.
My current understanding is that PPP does not spell out all possible
selections in each offer. Instead, it spells out one selection (e.g.,
"A2 and B1"). If that selection is rejected, a different selection is
provided (e.g., "A2 and B2"). There may be better places to quote, but
here is one direct quote from "6.2. Authentication-Protocol"
An implementation MUST NOT include multiple Authentication-
Protocol Configuration Options in its Configure-Request packets.
Instead, it SHOULD attempt to configure the most desirable
protocol first. If that protocol is Configure-Nak'd, then the
implementation SHOULD attempt the next most desirable protocol in
the next Configure-Request.
I am sending this message to provide an example where multiple offer
messages are used. I am not, at this point, advocating either approach
(a single complex and complete offer versus a series of simple
incomplete offers, each requiring immediate response). If you have any
preferences or suggestions, please voice them!
Thank you,
Alex.
P.S. I did not have enough energy/time to understand whether IKE and
IPSec support multiple offer messages within the same negotiation
phase. They do support multiple OR choices within one message.
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>
PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E