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

Richard Barr Hibbs <> Tue, 07 May 2002 23:55 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id TAA27368 for <>; Tue, 7 May 2002 19:55:44 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id TAA28958 for; Tue, 7 May 2002 19:55:52 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id TAA28791; Tue, 7 May 2002 19:51:41 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id TAA28766 for <>; Tue, 7 May 2002 19:51:40 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA27297 for <>; Tue, 7 May 2002 19:51:31 -0400 (EDT)
Received: from BarrH63p601 ([]) by (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <> for; Tue, 07 May 2002 16:51:38 -0700 (PDT)
Date: Tue, 07 May 2002 16:51:15 -0700
From: Richard Barr Hibbs <>
Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
In-reply-to: <>
To: Michael Carney <>, Steve Gonczi <>
Cc: "Cosmo, Patrick" <>,
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset="Windows-1252"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: []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??


dhcwg mailing list