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

Richard Barr Hibbs <> Tue, 07 May 2002 16:57 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA15660 for <>; Tue, 7 May 2002 12:57:24 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id MAA11249 for; Tue, 7 May 2002 12:57:31 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id MAA11127; Tue, 7 May 2002 12:55:23 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id MAA11099 for <>; Tue, 7 May 2002 12:55:21 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA15539 for <>; Tue, 7 May 2002 12:55:13 -0400 (EDT)
Received: from BarrH63p601 ([]) by (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <> for; Tue, 07 May 2002 09:55:19 -0700 (PDT)
Date: Tue, 07 May 2002 09:54:57 -0700
From: Richard Barr Hibbs <>
Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
In-reply-to: <>
To: Dhcwg <>
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: multipart/alternative; boundary="Boundary_(ID_cs62t8PGERKhF89vt+yseA)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

Interpretation of Option 60 (Vendor Class ID)If only the language used in
the RFCs was always precise, with well-understood meanings for all terms....

Is Vendor Class ID an octet string with no restrictions or a character
string?  If it is a character string, is it NVT-ASCII, UTF-8, or some other
encoding?  Is it a null-terminated string?

The word "octets" usually appears when no encoding (UTF-8, for example) is
implied or required, permitting binary values in the field, while "string"
usually means (and sometimes is actually specified in the definition of the
option) a character sequence encoded using NVT-ASCII.

In my opinion, Option 60 contains an octet string without any assumed
encoding.  As a practical matter, however, a string containing encoded
characters, for example, "SwampRat Model 66R IP Phone," has advantages for
implementors and field service technicians.

Finally, since all options contain a length octet, a null octet in an octet
string is NOT a terminator if it appears within the "n" characters specified
in the length octet.

There is the interesting case of a mixed encoded, unencoded string, such as
<character-encoded-part><unencoded-part><character-encoded-part>.  That
might be confusing for simple parsers, but certainly possible.

I've never liked the wording of this option description with respect to
interpretation by servers of the values, mostly because it provides little
guidance to implementors and leaves even the form of the value open to
discussion like this message thread.


  -----Original Message-----
  From: []On Behalf Of
Cosmo, Patrick
  Sent: Tuesday, May 07, 2002 06:41

  RFC 2132 states that option 60 "is a string of n octets". We are having a
little debate about how to interpret this and would like to know how others,
and the working group, interpret this option.

  Some of us feel that "octet != character" and that this _could_ be binary

  On the other hand, none of us are aware of any devices that send binary
(non-ascii) data for this option. This reinforces the opinion that the term
"string" implies a character string. Some of us all do not feel that the
word "octet" necessarily implies that these are not characters: since an
"octet" and a "character" are both a single byte, and for some character
tables (ISO-Latin-1) all values 1 - 254 are used as characters, with 0 being
the string termination character, the word "octet" does not necessarily
indicate that that this is binary data.