RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
Richard Barr Hibbs <rbhibbs@pacbell.net> Tue, 07 May 2002 16:57 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 MAA15660 for <dhcwg-archive@odin.ietf.org>; Tue, 7 May 2002 12:57:24 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11249 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 12:57:31 -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 MAA11127; Tue, 7 May 2002 12:55:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11099 for <dhcwg@optimus.ietf.org>; Tue, 7 May 2002 12:55:21 -0400 (EDT)
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15539 for <dhcwg@ietf.org>; Tue, 7 May 2002 12:55:13 -0400 (EDT)
Received: from BarrH63p601 ([64.170.116.122]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVR00KGT306RG@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Tue, 07 May 2002 09:55:19 -0700 (PDT)
Date: Tue, 07 May 2002 09:54:57 -0700
From: Richard Barr Hibbs <rbhibbs@pacbell.net>
Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
In-reply-to: <4FB49E60CFBA724E88867317DAA3D198692A12@homer.incognito.com>
To: Dhcwg <dhcwg@ietf.org>
Reply-to: rbhibbs@pacbell.net
Message-id: <JCELKJCFMDGAKJCIGGPNAEKHDMAA.rbhibbs@pacbell.net>
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
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
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. --Barr -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]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 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.
- [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