Subject: Re: Last Call on DHCP Options for SLP (fwd)

From: "Ralph E. Droms" <[email-masked]>
Date: Sun, 31 Jan 1999 17:47:43 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------------

> Do you object to the option going forward because you fear a precedent
> which will allow arbitrarily formatted options to be standardized?  I
> am certainly not attempting to open the door to that.  I explicitely
> asked the WG if they thought this particular format would be easy to
> implement on existing servers; the answer in Orlando was "Yes."

I did say in Orlando that this format is easy to implement, and
several of the other DHCP server implementors nodded and mmm-hmmed
sagely.  The objection previously was with putting bit-fields into an
option, not with putting more than one data type into the option.
There's no really special interpretation needed here - just two data
items of different types, concatenated.

I will admit that this is a bit harder than interpreting a single data
item, but I really think it's going too far to say that this is adding
another data type, or arguing that it shouldn't be done because it is
somehow hard to implement.

I suppose the counter-proposal would be to have two options, one of
which contains the boolean and one of which contains the the
UTF8-encoded name.  Given our determination to motivate ourselves to
implement wider option codes, I guess this isn't an entirely bad idea,
but we've been talking about this option for a *long* time.  The
current proposal is perfectly reasonable and implementable.  Requiring
Erik to go through yet another revision for the stated reason strikes
me as being unreasonable.

			       _MelloN_