Subject: How do you negotiate a numerical range?

From: Bill Studenmund <[email-masked]>
Date: Wed, 17 Jul 2002 14:11:08 -0700 (PDT)

I think I know the answer, but wanted to double check as AFAICT all the
numbers we have in the spec are either MIN or MAX; I suspect not much code
is using numerical ranges at the moment. Also, the spec doesn't say
anything about negotiating ranges AFAICT. :-)

Question 1:

Since all of the numbers we have are MIN or MAX, my understanding is that
you just take the min or max of the range, and use that for negotiation.

The initially-non-intuitive thing is that you can readily get a negotiated
value outside of the offered range. :-)

Consider an offer of "MaxConnections=3~10" to a device that wants
MaxConnections=2. Since MaxConnections is a MIN number, the correct
response (I believe) is "MaxConnections=2". I suspect however this might
seem counter-intuitive for new implementers.

Question 2:

Say you have a number that is not a MIN or MAX number (right now this'd be
a vendor-specific one), and you are offered a range (say "Foo=3~12"), and
had you made the offer you would have offered a different range (say
"Foo=10~16"). Do we want to say anything now about how to handle this
negotiation, or do we want to wait until we actually have a non-MIN/MAX
number in the spec?

I'd vote holding off, and just having everyone understand there will be
more work for some future version. :-)

Thoughts?

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Wed, 17 Jul 2002 21:29:42 -0400

> seem counter-intuitive for new implementers.

No, you are misreading the spec.

Only the marker interval parameters (OFMarkInt, IFMarkInt) permit
ranges.  It is not permitted for any other parameters (see section
4.2).

For range proposals, the responder must choose a value from within the
range, or Reject.  A response value outside the range is a protocol
error, the same way that picking a value not in the list for a list
type proposal is a protocol error.

MIN and MAX apply to parameters for which a single value is offered,
and the responder is allowed to negotiate down, or up, respectively.

> negotiation, or do we want to wait until we actually have a non-MIN/MAX

The rule for ranges is already specified (section 4.2.2): one side
proposes a range, the other side chooses from that range.  If someone
adds an X-foo parameter which is a range, that rule would apply.

	  paul

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 17 Jul 2002 18:41:13 -0700 (PDT)

> No, you are misreading the spec.

And as the last message I just sent indicates, I'm not the only one. :-)

> ranges.  It is not permitted for any other parameters (see section

You are correct. Search wasn't my friend on this one.

> and the responder is allowed to negotiate down, or up, respectively.

Never mind other note, except to the extent that MIN and MAX may have
weird semantics with respect to ranges.

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Thu, 18 Jul 2002 09:23:07 -0400

>>>>> "Bill" == Bill Studenmund <[email-masked]> writes:

 >> MIN and MAX apply to parameters for which a single value is
 >> offered, and the responder is allowed to negotiate down, or up,
 >> respectively.

 Bill> Never mind other note, except to the extent that MIN and MAX
 Bill> may have weird semantics with respect to ranges.

They aren't used with ranges, only with single number proposals.
Ranges are like lists, you must choose a value from within the range
(set) offered to you.  That's clearly stated in the spec.

      paul