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

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

> 
>  
> 
> /sG
> 
>     -----Original Message-----
>     From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
>     Cosmo, Patrick
>     Sent: Tuesday, May 07, 2002 9:41 AM
>     To: dhcwg@ietf.org
>     Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID)
> 
>      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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg