Re: A small change suggested

[Anders Andersson <[e-mail]>]

Peter writes:
>Well. I like the idea of "being liberal in what you accept, and
>restrictive of what you send out". Suppose the Ident data is transmitted
>over a line that converts all uppercase characters to lowercase....

I think that's a good principle to follow when doing implementations.
I'm not as sure that it's equally good when writing specifications,
such as this RFC, as that only creates an unintuitive gap between
what's formally required and what's useful.  Will people care to follow
the specification to the letter, when it's never necessary for real
use?  Who do you think is most likely to ignore the specification, a
server or a client implementor?  What if they both do?

As this isn't a protocol designed for human consumption or production,
allowing "UserID" makes as much sense as allowing "UID".  Any server
that is somehow unable to transmit some or all of the uppercase ASCII
letters will probably violate this and many other specifications as
well.  However, you are right that a case independent string comparison
routine is probably just as easily available as a case dependent one
(at least on Unix systems), and that for a negligible amount of extra
CPU time and memory, so I'll give you that the HLL programmer won't see
the extra 'complexity' he is required to add...

I think this has more to do with principles of protocol design than
with wasted resources, and I'll leave it at that.  This protocol has
more important aspects than the case of keywords, so I won't push it
at this last-minute (?) stage, just in case (!) somebody would like
to bring up a more urgent problem...
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 520, S-751 20 UPPSALA, Sweden
Phone: [phone]   EMail: [e-mail]