RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
Richard Barr Hibbs <rbhibbs@pacbell.net> Tue, 07 May 2002 23:55 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 TAA27368 for <dhcwg-archive@odin.ietf.org>; Tue, 7 May 2002 19:55:44 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28958 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 19:55:52 -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 TAA28791; Tue, 7 May 2002 19:51:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28766 for <dhcwg@optimus.ietf.org>; Tue, 7 May 2002 19:51:40 -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 TAA27297 for <dhcwg@ietf.org>; Tue, 7 May 2002 19:51:31 -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 <0GVR00A13MA1XZ@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Tue, 07 May 2002 16:51:38 -0700 (PDT)
Date: Tue, 07 May 2002 16:51:15 -0700
From: Richard Barr Hibbs <rbhibbs@pacbell.net>
Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
In-reply-to: <3CD81629.2060905@sun.com>
To: Michael Carney <Michael.Carney@sun.com>, Steve Gonczi <steve@relicore.com>
Cc: "Cosmo, Patrick" <Patrick@incognito.com>, dhcwg@ietf.org
Reply-to: rbhibbs@pacbell.net
Message-id: <JCELKJCFMDGAKJCIGGPNAEKMDMAA.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: text/plain; charset="Windows-1252"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
> -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]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?? --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [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