Re: Last Call: The Finger User Information Protocol to Standard

[Phil Budne <[e-mail]>]

I wish to protest the elevation of RFC1288.  In my opinion it and
it's predecessors RFC1196 and RFC1194 are poor replacements for
RFC742.  RFC1288's pseudo-rigor is obtrusive, and it appears to
endorse the behavior of just one implementation (and a broken one at
that).

1. It violates it's own intent;

   Based on RFC 742, a description of the original Finger protocol, this
   memo attempts to clarify the expected communication between the two
   ends of a Finger connection.  It also tries not to invalidate the
   many current implementations or add unnecessary restrictions to the
   original protocol definition.

1288 codifies the behaviors of the Berkeley 4.3 finger daemon, in
particularly the uselessness of /W.  Earlier versions invented
improvements like commas, and use of /W amidst the string.

2. It's terminology and notations do not add to the clarity of the
document; they are cumbersome and unnecessary.  Names like {Q1} and
{Q2} are far worse than english terms like "local query" and "remote
query".  Introduction of terms like "RUIP" is simple pointless, in the
old days we would have called it a server.  This is not ISO, we have
no mandate to make our standards equally incomprehensible to speakers
of all languages.

Regarding the Pseudo-grammar (section 2.2);

If I suspend disbelief that a grammar is not necessary, I find the
supplied grammar to be a mess, and not the result on anyone schooled
in formal languages.

* There is no definition of the language used to represent
the "grammar".

* "{name}" is an unconventional choice for bracketing token names,
<name> would be a more traditional choice.

* There are no clear notational conventions for terminals. All three
of the following describe terminals;

        {U}     ::= username
        {W}     ::= /W
        {C}     ::= <CRLF>

There is no need for the "non-terminal" symbols U, W, and C.  Direct
use of terminal symbols (ie; <USERNAME>), quoted strings (ie; "/W"),
or implicit end of line would server as well, or better.

* There is no "start symbol or rule. One is left to presume the
existence (to degenerate momentarily into the author's alphabet soup)
of a rule "{Q} ::= {Q1} | {Q2}"

4. The only useful issue raised by 1288 are the security concerns,
particularly those surrounding "remote queries", and the document
states pretty clearly that this was not the author's work.

The other issue of "interest" is the local name ambiguity (is the name
in the query a local username, a human last name, etc).  As the author
of three finger implementations (TOPS-10, TOPS-20 and Un*x) I feel the
ambiguity is obvious to anyone skilled in the art.

Furthermore this is not an RFC on implementing FINGER, but a protocol
for accessing finger implementations.  It is my assertion that the
interpretation of "local queries" is one left to the author of the
finger program.  This is particularly irksome given that the author
shows examples of an implementation that flies in the face of the one
element of the protocol which requires standardization; interpretation
of the "/W" switch.

5. While ITS and SAIL are no longer in production, the examples in
RFC742 show diversity and a possible range of implementations.  There
was no need to remove them.

RFC1288 appears to show example output from only one implementation,
the finger/fingerd from 4.3 BSD Un*x.  This implementation has
behavior which makes the "/W" flag nearly useless, and while it may be
the most commonly distributed implementation, it not by any means the
only implementation.  Even on Un*x, there are other better, examples
which should be cited, shown, or followed.

Try finger @gyre.cs.umd.edu, cunixf.cc.columbia.edu, gnu.ai.mit.edu,
or shiva.com to see just four Un*x alternatives.  Furthermore there
are systems other than Un*x.  I am aware of at LEAST one VMS finger
implementation, and I know one exists for VM/CMS.

In summation, I find RFC1288 to be dangerously revisionist. While this
might be seen as excusable given the circumstances that FINGER is a
minor protocol, it seems to me to be perilously close to endorsing
revisions of other, more important protocols based on the behavior of
poorly written, but widely distributed implementations.

Should SMTP (RFC821) be revised to specify (or show by example) that
VRFY is a synonym of EXPN or that SAML/SOML/SEND were useless because
the authors of sendmail didn't implement them correctly?

Should FTP (RFC959) be revised to specify (or show by example) that
transfers NOT using the PORT command can be ignored?

Should TCP be revised to specify that the ability to establish passive
endpoints with explicit foreign address (so that you CAN implement FTP
without the PORT command) is unimportant?

Should RFC's suggest that a user TELNET that is NOT able to
transparently send the escape character through by typing it twice, or
an FTP program which can't disambiguate "q" to mean "quit" is the best
that can be done?

Yes, the folks of CSRG should be applauded for having brought TCP/IP to
a larger community of users.  But we should not forget that superior
implementations do exist, and did exist long ago.

Some of us still remember.

Phil Budne
System Architect
Shiva Corporation