RE: Problem with use of NotUnderstood in negotiations

[Bart Crane <bcrane@iready.com>]

Title: RE: Problem with use of NotUnderstood in negotiations

This new rule is not necessary.

Sec. 4.2 says:

   The constants None, Reject, Irrelevant, and NotUnderstood
   are reserved and must only be used as described here.

In the situation you describe, the sender will be expecting
a response to "keyA", but the key-name was corrupted to "keyB".

The receiver does not understand "keyB", and so responds with
"keyB=NotUnderstood".

To the sender, this appears to be the start of negotiating a
new key, "keyB", with the value "NotUnderstood". 

But, this is not a valid use of the value "NotUnderstood",
so it is a protocol error.

So, the new rule of not-responding to keys with the value
"NotUnderstood" is not necessary.

Bart.

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Friday, August 09, 2002 9:12 AM
To: ips@ece.cmu.edu
Subject: Problem with use of NotUnderstood in negotiations

I encountered a problem with how draft 15 specifies using NotUnderstood as
a reply to keys that aren't understood. Namely if something injects
garbage into the negotiation stream we can end up with a key BOTH sides
don't understand, and so they both sit there sending "foo=NotUnderstood"
back and forth to each other.

Yes, well-behaved negotiators won't offer a key they don't understand. But
the data stream can be corrupted, and all it would take is a single-bit
error in a key name and we encounter the above.

I propose we change the text to:

Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. If the value for the key was "NotUnderstood", the
acceptor MUST not answer the key.

Note: I can easily see closing the connection with an error in the above
case too.

Thoughts?

Take care,

Bill