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

[Karl Denninger <[e-mail]>]

> Karl Denninger <[e-mail]> writes:
> 
> >> 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. 

Ok, I've pulled the RFC documents and read them.

What I see are two >very< similar protocols.  Similar enough that with a
>little< work the WG could easily make them, for all intents and purposes,
be 100% end-user compatible and upwardly mobile.

So why not do it folks?  (this question is directed to BOTH Bernstein and
the IETF people)

> 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).

Then let's follow the principle of "be generous in what you accept, and
strict in what you generate" and find common ground here from a user
perspective.  It >is< possible from what I have read, and its not a lot of
work to do it.  

Doing this requires that the IETF Working Group stop politicking (and that
goes for Dan too) and do their job, which is to provide RFCs and standards
that benefit the user community.  The point here being that if I am a
secretary at a corporation, and I try to mail or FTP something, I don't care
>why< it doesn't work the way I expect -- what I care is that it doesn't.
Same for most "non-computer geek" types.

Let's bury the hatchet (not in anyone's head either) and resolve the
differences in these two specifications so they can work >together<.  The
back-end protocol engines aren't important to users -- what IS important is
interoperability and upward compatibility so that applications don't break.
I have every reason to believe that this is achieveable given what is
written in those specifications.

> /Peter Eriksson <[e-mail]>

-- 
Karl Denninger ([e-mail], <well-connected>!ddsw1!karl)
Data Line: [[phone]] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions