Comparison of ident and rfc931

Frank Kastenholz <kasten@ftp.com> Thu, 10 September 1992 12:58 UTC

Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02612; 10 Sep 92 8:58 EDT
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa08295; 10 Sep 92 9:01 EDT
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02604; 10 Sep 92 8:58 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02579; 10 Sep 92 8:57 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08284; 10 Sep 92 9:00 EDT
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6) id <AA05185>; Thu, 10 Sep 1992 06:00:31 -0700
Received: by ftp.com id AA26533; Thu, 10 Sep 92 09:00:15 -0400
Date: Thu, 10 Sep 1992 09:00:15 -0400
Message-Id: <9209101300.AA26533@ftp.com>
To: Stef@nma.com
Subject: Comparison of ident and rfc931
From: Frank Kastenholz <kasten@ftp.com>
Cc: jnc@ginger.lcs.mit.edu, ietf@isi.edu

stef

i did a 10-minute-early-morning-not-yet-finished-my-coffee review of
931 and the ident draft. by and large, the syntax and semantics of the
protocol that they describe are the same. much of the difference between
the two documents seems to be tightening up the wording, cleaning up the
formal syntax and so on -- basically editorial in nature.

there is one significant syntactical difference between the two.
the normal response is to give a 4-tuple of server and client port
number, operating system type, and user id. the o.s. type field
basically declares what operating system the thing is running on
and therefore pretty much descibes what the format of the user-id field
is. in rfc931, the os field was a character string that had the name
of the os in it. in ident, this field has been extended to include
an optional character set indicator. the format of the field was:
	:<os-type>:
(the :s are field separators in the response) and it now can be either
	:<os-type>:
or
	:<os-type>,<charset>:
<charset> identifies the character set that the userid is in. it can be
OCTET, indicating that the userid is anything. this is the default.
ident also explicitly states that the userid field can be anything
if the char set is OCTET (which is the default). rfc931 makes no mention
of what the valid characters are for the userid. a robust implementation
ought to allow for any userid characters.

in ident, the <os-type> and <os-type>,<charset> fields are defined as being 
only ascii characters, and : is not allowed in there. thus, if a rfc931
client makes a query of an "ident" server and the server responds with
a <os-type>,<charset> the rfc931 client should, if the implementor has followed
the robustness principle, merely see an operating system name of, e.g.,
"unix,us-ascii"

as i said, this is a 10-minute-early-morning-not-yet-finished-my-coffee
review. i have not implemented either protocol.

also, i have elected not to review tap because it is an effort outside of
the ietf process. pedantically, anything that goes on on port 113 other
than rfc931 is a private matter between consenting systems and is none
of the ietf's institutional business.

--
frank kastenholz