Subject: Re: Vendor Info

From: "Mark Meredith" <[email-masked]>
Date: Tue, 15 Feb 2000 11:51:57 -0700

I had intended these to only be set by the developer of the server on compile time. I feel that if you are able to change the values then there is really not any better than not having the values, I would like to have some confidence that the information if provided is accurate according to what the developer put there is valid.

As for changing the wording . "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, ..."
What word would you recomend to clarify recognize? Or how would you re-word it to take recognize out or make it more solid (clear).

-Mark

>>> "Kurt D. Zeilenga" <[email-masked]> 02/14/00 08:03PM >>>
At 07:12 PM 2/14/00 -0700, Jim Sermersheim wrote:
>>Section 5.
>>
>>If a server supports these attribute types, the values should
>>be overwritable by configuration.  This allows a server to
>>"spoof" clients to obtain desired behavior.
>
>Are you requesting that this wording be added to the draft? If so, why? Perhaps your should should've been a shouldn't?

I suggest using wording similiar to that found in the RFC 2616 (HTTP 1.1):
  Server implementors are encouraged to make the values of these
  attributes configurable options.

Note, they encourage suggest for security reasons.  Though quite valid,
I suggest it primarily for interoperability.  I've already seen folks
hack OpenLDAP to spoof other servers so that they could use some client
which inappropriately depended provided vendor information.  [In
believe the vendor ended up hacking their own server to spoof the
old version so that their client would work].

>>Clients should not attempt fuzzy matching.  They must only
>>enable workarounds when the server presents a vendor strings
>>known to evident of specific flaws.
>
>While this may be good advise, I don't see it as a requirement. If a client writer knows that versions 5.0 thru 5.x all exhibited a certain bug, and it was fixed in 6.0, it's reasonable for them to assume that a version substring of 5. will exhibit the bug.

No, because the vendor may, even after producing 6.0, produce a 5.y which fixes
the behavior.  This sometimes occurs because a large customer of the vendor
specifically requests a patch for the older version and the vendor complies.
It is not uncommon for a vendor to support and revise multiple versions
for significant time.

>>  They must assume that all
>>unknown vendor strings behavior per standard track specifications.
>
>Are you requesting that this wording be included in addition to, or in lieu of: "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, then for the purposes of 'working around' anomalies, the client MUST assume that the server is complete and correct."?

I would prefer to clarify the term "recognize".

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Feb 2000 13:12:06 -0800

>I had intended these to only be set by the developer of the server on compile time. I feel that if you are able to change the values then there is really not any better than not having the values, I…

You have already dismissed the accuracy of the provided information:
   Client and application implementers must consider that
   the existence of a given value in the vendorName or vendorVersion
   attribute is no guarantee that the server was actually built by the
   asserted vendor or that its version is the asserted version and
   should act accordingly.

You'll note that most web servers have the HTTP product tags
defaults generated as part of their build system, but allow
the local administrator to override these values.  This gives
the flexibility to the local administrator which is where it
should be.

>What word would you recomend to clarify recognize? Or how would you re-word it to take recognize out or make it more solid (clear).

Something like:

If the vendor string does not exactly match vendor information
known to flawed, the client MUST NOT alter its behavior.  The
client SHOULD NOT use "fuzzy" or "wildcard" matching of vendor
information to determine its behavior.