TAP is not proprietary

["Daniel J. Bernstein" <[e-mail]>]

Ran Atkinson states that TAP is ``Dan's proprietary protocol,'' and
attempts to use this to justify IDENT's use of TCP port 113. His
statement is false in at least two senses.

First, TAP is, by definition, the protocol actually used on port 113 of
the Internet. Yes, I was the first person to implement it (in early
1990), but other than that I haven't controlled its use in any way. You
can pick up a list of the 179 TAP server sites I know about from
128.122.142.2 port 19313. Several independent interoperable client and
server implementations and applications, from quite a few people, appear
in ftp.lysator.liu.se:pub/tap. And more than 150 people subscribe to the
rfc931-users mailing list. It is the voluntary compliance of members of
the user community, not any ``proprietary'' action, which has kept the
protocol interoperable so far. (I am the first to admit that an RFC
describing the protocol would help guarantee future interoperability,
but all my attempts to publish such a RFC have been stymied.)

Second, TAP has been documented by a completely open ad-hoc working
group, TAP-std. TAP-std is chartered to document the TAP protocol as
used on port 113 of the Internet. As of now there's a motion on the
floor to publish the current TAP specification by any means at our
disposal. The tap-std mailing list is open and has more than fifty
subscribers. As group chairman I've stated my policies for guaranteeing
open discussion. You can pick up the TAP-std summary sheet by connecting
to 128.122.142.2 port 49310.

So neither the TAP implementations nor the TAP protocol specifications
are proprietary. Any accusations that TAP has taken over port 113 must
be levelled at the current users as a whole, not at me.

Ran suggests that IDENT's compatibility problems are my fault: he says I
should have found a new port to run TAP, or ``just'' used RFC 931. This
suggestion is both naive and misleading. RFC 931 had one technical
problem (quoting), which I ignored in my first implementation in early
1990; and it was very poorly defined in several respects (e.g., the
exact placement of whitespace), which I made clear in my first TAP
specification in June 1991. Other than this TAP and RFC 931 are the
same.

Why should TAP's users have avoided port 113? When I came along, RFC 931
was ``experimental''---yet I still came so close to implementing it that
for two years I didn't even bother giving TAP its own name. Except for
RFC 931's quoting of spaces and other special characters in unusual
situations, any RFC 931 implementation will talk happily with TAP.

The same cannot be said for IDENT. An IDENT client, for instance, must
understand character sets: a typical RFC 931 implementation wouldn't
have the slightest idea how to handle a UNICODE identifier (maybe with
embedded nulls and line feeds) transmitted by an IDENT server. If
compatibility with RFC 931 is a criterion, IDENT fails.

Who thinks IDENT is ``in fact the RFC-931 successor and should use port
113,'' as Ran says? Certainly not the current users of the port---IDENT
hasn't even been implemented. Mike StJohns was the one who refused to
change the port number back in May when I made the suggestion; but I
don't think his attitude towards compatibility is shared by most of the
IETF. For example, he has said: `` ... "Objection: Doesn't meet current
practice" which by the way isn't a valid objection for anything at the
pre-Proposed Standard level.''

*What are the disadvantages of giving IDENT a new port number?* How come
nobody ever seems to answer this question?

---Dan