[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?
- [dhcwg] Interpretation of Option 60 (Vendor Class… Cosmo, Patrick
- Re: [dhcwg] Interpretation of Option 60 (Vendor C… Bud Millwood
- RE: [dhcwg] Interpretation of Option 60 (Vendor C… Steve Gonczi
- RE: [dhcwg] Interpretation of Option 60 (Vendor C… Richard Barr Hibbs
- Re: [dhcwg] Interpretation of Option 60 (Vendor C… Michael Carney
- RE: [dhcwg] Interpretation of Option 60 (Vendor C… Richard Barr Hibbs
- RE: [dhcwg] Interpretation of Option 60 (Vendor C… Patrick Guelat
- Re: [dhcwg] Interpretation of Option 60 (Vendor C… Ted Lemon