RE: Problem with use of NotUnderstood in negotiations

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 9 Aug 2002 pat_thaler@agilent.com wrote:

> Bart,
>
> So the question is, in what order does a device do the checking.
>
> There are many possibilites for handling a received key that is
> unknown and comes in with the value unknown:
>
> A) Check key
>        if key unknown, send key=NotUnderstood
>          else ...process key=value pair
>
> B) Check key
>        if key unknown
>          if value=NotUnderstood silently drop (or close connection)
>            else send key=NotUnderstood
>
> I expect case A is more likely to get implemented in the absence
> of an explicit statement. There would normally be no need to
> examine the value of a key when one doesn't understand the key.
> In this case, the receiver never does a test that detects the
> apparent protocol violation of making an offer with a value
> NotUnderstood.

Actually, reading the spec, it's worse than that. The spec says if you
don't understand the key, you MUST answer NotUnderstood. Doesn't matter
what the value is, "MUST" is in there. So it's arguable that while case A
isn't what we want, it more closely conforms with the wording of the spec
than does case B.

The problem is that "strange_key=NotUnderstood" looks like two different
protocol issues, we give no guidance as to which one is more important,
and the different issues have different resolutions. One resolution has
MUST attached to it that will lead to more trouble.

> So, if we want to stop the loop that Bill has found, we should
> put in an explicit requirement to test the value for NotUnderstood
> before responding to a key with NotUnderstood.

In my thoughts now, it's more we want a release from the MUST assosciated
with keys we don't understand. I've changed my mind since I first posted.
I now think the best thing to do is say if you get a key you don't
understand and its value is NotUnderstood, you call it a protocol error.
That way it doesn't matter if you look at the key or the value first, you
arrive at a protocol error (and you sending nothing) either way.

Take care,

Bill