Subject: Suggested changes to RFC2132

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Apr 1999 11:45:18 -0400 (EDT)

In RFC2132, in section 2, paragraph 1, there is a requirement as
follows:

   "Options containing NVT ASCII data SHOULD
    NOT include a trailing NULL; however, the receiver of such options
    MUST be prepared to delete trailing nulls if they exist.  The
    receiver MUST NOT require that a trailing null be included in the
    data."

This text should be deleted, and no text added to address this
problem.

In order to implement this requirement, the DHCP server or client
needs to know which options are stored in NVT ASCII.  Some options
(e.g., the DHCP client identifier) may be either NVT ASCII or binary,
depending on the context.  Also, new options may be developed in the
future, and there is no guarantee that existing servers will know
their format.  So it is not reasonable to assume that the server or
client will always know that an option's format is or is not NVT
ASCII.

This requirement is here solely to accomodate broken Windows 95
clients, AFAIK.  Because it is present I have had several people say
to me that the broken Windows 95 client is in fact in compliance with
the standard because this requirement is stated in the specification.

I don't believe it is an error for a DHCP server to try to deal
correctly with clients that send NUL-terminated NVT ASCII strings, but
in fact the disputed requirement doesn't completely specify this - in
order to interoperate with broken Microsoft DHCP clients, the DHCP
server must in fact always NUL-terminate NVT ASCII strings that it
sends to the client.

Because this statement is only present to accomodate a buggy client,
because the implementation of the required behaviour is complicated,
because the statement doesn't completely specify the correct
behaviour, and because complete correctness would be impossible to
demonstrate, this requirement does not belong in the standard.

I think the old maxim, "be liberal in what you accept, and
conservative in what you send" addresses this issue to the extent that
it needs to be addressed.  If not, a complete description of the
problem and its suggested solution should go in a document on best
current practices or implementation considerations.  It should _not_
be a SHOULD or a MUST in the standard.

			       _MelloN_