RE: Problem with use of NotUnderstood in negotiations

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Sun, 11 Aug 2002, Julian Satran wrote:

> Bill,
>
> My only intention in the note was to be brief.  If you viewed that as rude
> I am really sorry.
> I have a lot of mail to reply to and a limited time.

And my appologies if I saw rudeness that was not intended.

> As for the crux of the matter - if one of the parties receives a key it
> has not seen before
> with NotUnderstood as value it MUST act on it as a protocol error. The
> text is unambiguous on this.
> However we may want to strengthen the rule in 4 (and add another line of
> text) as follows:
>
> The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
> reserved and MUST ONLY be used as described here. Violation of this rule
> is a protocol error (in particular the use of "Reject", "Irrele-vant", and
> "NotUnderstood" as proposed values).

Ok. That would work. Also see my proposed text that crossed this one in
the mail.

> In the second part of my comment I was just saying that if you  failed to
> implement the above check you still can't enter a loop
> because the double negotiation rule.
>
> To get you in a loop in which every party think it answers - then either
> both are buggy or somebody is altering the messages maliciously.
> The protocol is not designed to handle either.

But do we need to remember keys we didn't understand? I hadn't taken that
away from the spec before now; I (and others, as evidenced by code :-)
thought it was safe to just respond and be on with it. For the
double-negotiation rule to catch it, we have to remember them.

Is that really what we want? I have this unplesant image of one side
wanting to try a whole lot of vendor keys (different vendors), and the
other side being a simple negotiator and getting overwhelmed.

Take care,

Bill