IDENT vs TAP vs RFC931 (Was: Re: bernstein's protocol)

[[e-mail]]

Karl Denninger <[e-mail]> writes:

>> Now, if Bernstein and his friends want to use their version instead of
>> what came out of the IETF ident WG, it's their problem. Not every
>> protocol running on the Internet has IETF/IESG/IAB approval, and no
>> Network Police is going to stop them. If he is so upset with the way
>> we operate, why is he seeking our approval?
>
>Perhaps because he is upset (and, IMHO, rightly so) that a committee has
>decided to place an incompatible protocol on top of a known and used
>namespace (in this case tcp port 113)?  I think that's plenty of reason 
>to complain, and loudly.

Sigh. I keep hearing all this stuff about "incompatible protocols"
all the time and I'm getting really tired of it. It sounds like
IDENT and TAP would be two totally different creatures, when they
in the real world aren't. Check out the two documents if you don't
believe me. Available via anonymous FTP from ftp.lysator.liu.se
in pub/ident/doc (. also known as pub/tap/doc, just to make sure I'm
politically correct .) and via our MAIL server. send mail to
the address [e-mail] with a message body of:

  SEND pub/ident/doc/TAP.RFC
  SEND pub/ident/doc/IDENT.RFC

>> With all the problems facing the Internet, one would think that our
>> time would be better spent on other things.
>
>Right.  If that was the purpose of the IETF WG in question then why not
>assign a different port number and be done with the controversy?  I find 
>it interesting that they would choose to "step on" users of the existing 
>port 113 mechanism.
>
>I believe that it would be in the Internet's best interest if this working
>group were to assign a different, non-conflicting port number for their
>proposed protocol.  This WG has the power to put out the flame-war with
>a simple declaration.  I can't see a >technical< reason for choosing port
>113; I can see plenty of politically-motivated reasons, and frankly, I think
>those have no place in a standards committee.

I disagree. There is NO need for two almost identical protocols on the
internet. And if the IDENT protocol should use another port, then so
should TAP, since TAP isn't compatible with RFC931 either (in the strict
sense - it doesn't implement the quoting of characters RFC931 specify).

>If there is a technical reason for using port 113 then let's hear it.  I
>can't imagine what that reason might be unless the intention was to maintain
>backward compatability -- which is clearly not the case from the
>descriptions I have seen published here.  If, however, the reason is simply
>to step on someone who is an "outsider" from the WG process then I find these 
>actions without merit and deserving of public criticism.

Go read the documents and see for yourself instead of believing what is
written here.

Here are the major differenses and the compatibilitie issues involved:

1. An IDENT client talking to a TAP server will work just fine.

2. A TAP client talking to an IDENT server will be able to retrieve
   the user name just fine. Where it can be confused is when it is
   to handle the <operating system> token since that has been extended
   in the IDENT protocol to optionally include an character set token.
   However, the current TAP client implementation that is in use in most
   cases doesn't handle the <operating system> token at all so that doesn't
   matter much.

For example: An IDENT server may return either

	47 , 4711 : USERID : UNIX : pen

or:
	47 , 4711 : USERID : UNIX , ISO8859-1 : pen

Whereas a TAP server only will return the first of them. So a TAP client
implementation might return as an operating system the string:

	"UNIX , ISO8859-1"

It wouldn't be that difficult to fix the TAP protocol so that it
states that the operating system identifier shouldn't include anything
after the first ",". And since the current implementations doesn't
handle the operating system token anyway this wouldn't break anything.

And yes, Dan has a small point when he talks about the possibility of
an IDENT server returning responses using lowercase tokens. However,
that wasn't the intention when the IDENT protocol spec was written and
I've now pointed that out on the IDENT mailing list and asked that the
language in the document about this issue be cleared up.

I'd also like to point out that there are implementations of the IDENT
protocol out there that are in use today. Although most people doesn't
use the IDENT client library since it's not really needed unless one
desperately wants the operating system and/or the character set tokens.

"ftp.lysator.liu.se:pub/ident/servers/pidentd-2.0.tar.Z" is a server that
can act as an IDENT or a TAP server. To enable the IDENT-specific features
you add a command line option.

"ftp.lysator.liu.se:pub/ident/libs/libident-0.1.tar.Z" implements a small
IDENT client library. With it is a small example server that implements
a simple IDENT/TAP-server-tester included. This library can also be used
to talk to TAP servers. 

/Peter Eriksson <[e-mail]>