Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID)

From: "Cosmo, Patrick" <[email-masked]>
Date: Tue, 7 May 2002 06:40:31 -0700

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?

---

From: Bud Millwood <[email-masked]>
Date: Tue, 7 May 2002 16:36:52 +0200

On Tuesday 07 May 2002 15.40, you wrote:

> little debate about how to interpret this and would like to know how
> others, and the working group, interpret this option.

I went back and forth on this, and finally decided the best approach was to 
present it as a string, but allow escape sequences in the string so the user 
can at least work with non-printable characters if need be.

> be interpreted as a string?

Experience with my customer base has shown that they (and/or their devices) 
expect it to be a string.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Steve Gonczi" <[email-masked]>
Date: Tue, 7 May 2002 11:53:52 -0400

Interpretation of Option 60 (Vendor Class ID)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)

/sG
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Cosmo, Patrick
  Sent: Tuesday, May 07, 2002 9:41 AM
  To: [email-masked]
  Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID)

---

From: Michael Carney <[email-masked]>
Date: Tue, 07 May 2002 11:00:09 -0700

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
> 
> Because the authors did not restrict the allowed octet values in any 
> way, we can not safely
> 

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 ;^)]

>      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.
> 
>      
> 

-- 
Mike Carney                                Sun Microsystems, Inc.
Solaris Networking Technology              Mailstop UMPK17-202
The noise electric never stops             901 San Antonio Rd
(650) 786-4171                             Palo Alto, CA 94303

---

From: Richard Barr Hibbs <[email-masked]>
Date: Tue, 07 May 2002 16:51:15 -0700

> Michael Carney
> Sent: Tuesday, May 07, 2002 11:00
>
>
> Steve Gonczi wrote:
>
> > a specific character set, or required zero termination if they had  that
> > in mind.
> >
> > way, we can not safely use a zero termination convention. ( embedded
> > zeros are allowed by the definition)
>
>

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

---

From: Patrick Guelat <[email-masked]>
Date: Wed, 8 May 2002 09:00:52 +0200

Steve, I agree with you that there is no implication on the
character set to be used. But the term 'string' implies for
me that it `could' be zero terminated, i.e. that it's ok
to treat zero as a termination character in that case.

If this is not the case, 'string' should be changed to
'array' imho.

	-Patrick

--
Patrick Guelat, ImproWare AG Network Services, CH-4133 Pratteln
Mail: [email-masked] - Phone: +41 61 826 93 00 (ext: 13)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 May 2002 16:46:51 -0500

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.   
:'}