Re: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
Ted Lemon <Ted.Lemon@nominum.com> Wed, 08 May 2002 21:50 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 RAA24757 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 17:50:48 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00652 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 17:50:55 -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 RAA00488; Wed, 8 May 2002 17:47:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00461 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 17:46:58 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24689 for <dhcwg@ietf.org>; Wed, 8 May 2002 17:46:49 -0400 (EDT)
Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g48LjrS10411; Wed, 8 May 2002 14:45:53 -0700 (PDT)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g48Lkq600544; Wed, 8 May 2002 16:46:52 -0500 (CDT)
Date: Wed, 08 May 2002 16:46:51 -0500
Subject: Re: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v481)
Cc: Steve Gonczi <steve@relicore.com>, "Cosmo, Patrick" <Patrick@incognito.com>, dhcwg@ietf.org
To: Patrick Guelat <patg@imp.ch>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <Pine.SGI.4.33.0205080856390.466610-100000@harem.imp.ch>
Message-Id: <1B41C9AC-62CD-11D6-A5AB-00039367340A@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
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
At this point, there is no way to undo the misunderstanding about option 60. You can't count on it being ASCII text. If you get an option from a client that might be a string, and might be zero-terminated, that doesn't mean you should ever pass it to strcmp(). The presence of zero-termination in rfc2131 is a mistake. It shouldn't be there. It's documenting the behavior of certain broken clients, which is not something an RFC should do, and it does it in a way that encourages new implementors to implement their clients in a broken way, which is really bad. If you are implementing a client, do not ever zero-terminate. Then you won't have to worry about this. If you are implementing a server, and the user supplies you with ASCII text, then when comparing that ASCII text with the option's value, if the last byte in the option is zero, you can decrement the length of the option value sent by the client before doing the comparison. If the user supplies you with binary data, you have to do a binary comparison - if there's supposed to be a zero at the end, the user has to supply it. There's no reason to make this any more complicated than it already is. :'} _______________________________________________ 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