RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID)

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> Michael Carney
> Sent: Tuesday, May 07, 2002 11:00
>
>
> Steve Gonczi wrote:
>
> > IMHO it is meant to be an array of  unsigned bytes.
> >
> > The authors would have spelled out any formatting restrictions, such as
> > a specific character set, or required zero termination if they had  that
> > in mind.
> >
> > You will see that they did so in other cases.  ( e.g.: section 9.9).
> >
> > Because the authors did not restrict the allowed octet values in any
> > way, we can not safely use a zero termination convention. ( embedded
> > zeros are allowed by the definition)
>
>
> Sigh. Actually, it was intended to be an ASCII (printable) string of
> some value to the client vendor (OS). To the server(s), it's just an
> opaque string of characters. I originally wrote the text for this back
> in '93. I suspect my fervor for ensuring that servers would treat the
> value as opaque lead to my use the term "octets".
>
> [Diving under desk to avoid incoming missiles ;^)]
>

no missiles, brickbats, or other detritus....  when I re-read this section
of the RFC earlier today, I was left with the impression that the octet
string was NOT opaque, else it would be impossible for the vendor to
"...choose to define specific vendor class identifiers to convey particular
configuration or other identification information about a client," or to
"...encode the client's hardware configuration," which would be the basis
for an Option 43 reply.  *sigh*

Mike, I agree that a character-encoded identifier is often much easier for
implementors and technicians, but I'm not sure that the string is
necessarily opaque to be useful.  An opaque string would imply that the
vendor supplies some magic values to be returned in option 43 if a specific
string is encountered in option 60 -- the server need not interpret the
value of option 60, just recognize it.  But my sense is that option 60 is
just one piece of information used by a server to formulate an option 43
response, which means that the server must have some idea of the "meaning"
of the vendor class identifier.

Having said that, I think a perfectly valid use of option 60 does not
require option 43 in the response.  For example, suppose you had a hardware
printer server that would fail to initialize properly if sent an option it
did not expect, but it sent a unique class identifier.  A DHCP server could
then avoid sending things unrecognized by the device, such as "Default IRC
Server," and not send anything at all in option 43.

Ain't semantics, syntax, and semiotics wunnerful??

--Barr

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg