[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: No-op LDAP ;binary option



At 10:47 AM 2002-11-22, Jeff Jacoby wrote:
>I think of this is the Tomato Solution:

>  You say you want a to-MAH-to?  I'll give you this red juicy thing that 
>  goes well on salads...and we'll both call it a to-MAH-to.
>  Oh, you say you'd prefer a to-MAY-to?  Then I'll give you this red
>  juicy thing that goes well on salads...and we'll both call it a
>to-MAY-to.


Well, the issue is more that you ask for "to-MAH-to" and the
waiter says "what?".  And then I ask a waitress for "to-MAY-to"
and she says "what?".

Now, in the real world, the waitress can bring out the chief.
So, I ask for "to-MAY-to"?  The chief says "to-MAT-to?" and
I reply "what?"

The problem here is that we've said that if you want to order
tomatoes you need to ask for them as "tomatoes" (in print)
and you need to server them with a label that says "tomatoes"
(in print).

Now, what some have said is, if the server recognizes an
odd spelling of tomatoes, it can serve the dish with that
old spelling.  There are odd clients which expect this.
Unfornately, we have also have odd clients which actually
expect to be able to be able to ask for the dish using an
odd spelling but get back the correct spelling.  So, what's
the server to do?   Serve two dishes, one labeled each way?
Or guess at what the client wants?  Or just refuse to server
anything unless the client learns how to spell it correctly?

The plan we've put into place realizes that many tomato
stands may be flexible in how they handle requests from odd
clients and places no new restrictions on their handling.
A server is free to recognize an odd spelling, free to
label the dish with this old spelling or the correct
spelling.  The only thing we'd like to say those, is that
the dish is to served raw (DER) regardless of how its
labeled... but that any request or dish labeling other
than the standard one is deprecated.

Kurt