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

"Cosmo, Patrick" <Patrick@incognito.com> Tue, 07 May 2002 13:36 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07491 for <dhcwg-archive@odin.ietf.org>; Tue, 7 May 2002 09:36:09 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25573 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 09:36:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25399; Tue, 7 May 2002 09:34:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25372 for <dhcwg@optimus.ietf.org>; Tue, 7 May 2002 09:34:38 -0400 (EDT)
Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07400 for <dhcwg@ietf.org>; Tue, 7 May 2002 09:34:30 -0400 (EDT)
Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 175501-0008Cg-00 for dhcwg@ietf.org; Tue, 07 May 2002 06:27:25 -0700
Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8S1HV>; Tue, 7 May 2002 06:40:31 -0700
Message-ID: <4FB49E60CFBA724E88867317DAA3D198692A12@homer.incognito.com.>
From: "Cosmo, Patrick" <Patrick@incognito.com>
To: dhcwg@ietf.org
Date: Tue, 07 May 2002 06:40:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5CC.C169BB70"
Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

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
data.

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.

comments?

does anyone know of any devices that send data for this option which cannot
be interpreted as a string?