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