Ident/931 review

"David A. Borman" <dab@berserkly.cray.com> Mon, 21 September 1992 19:21 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15064; 21 Sep 92 15:21 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15060; 21 Sep 92 15:21 EDT
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa23346; 21 Sep 92 15:25 EDT
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15028; 21 Sep 92 15:21 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15024; 21 Sep 92 15:20 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa23225; 21 Sep 92 15:24 EDT
Received: from handel.cray.com by cray.com (4.1/CRI-MX 2.2) id AA14603; Mon, 21 Sep 92 14:24:31 CDT
Received: by handel.cray.com id AA07033; 5.57/CRI-5.5; Mon, 21 Sep 92 14:24:16 -0500
Date: Mon, 21 Sep 1992 14:24:16 -0500
X-Orig-Sender: ident-request@ietf.nri.reston.va.us
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: "David A. Borman" <dab@berserkly.cray.com>
Message-Id: <9209211924.AA07033@handel.cray.com>
To: ident@NRI.Reston.VA.US, iesg@NRI.Reston.VA.US
Subject: Ident/931 review

Here is a comparison of interoperability issues between RFC-931,
Ident, and TAP.  This is a slightly updated version of what I sent
to the iesg mailing list a week or two ago.

			-David Borman, dab@cray.com

Summary
=======

The main question that this review is intended to answer is whether
or not Ident should be assigned a new TCP port number, distinct from
the port number assigned in RFC-931.  The only reason for assigning
a new port number would be if Ident implementations would not
interoperate with existing implementations.  It seems to me that
the potential interoperability problems are pretty easy to fix.

Suggestions
-----------

To increase interoperability of Ident with RFC-931 (and TAP), the Ident
spec should be modified to:
	1) disallow white space at the beginnings
	   and ending of lines.
	2) Disallow white space before and after the ","
	   that separates <opsys> from <charset>.
	3) The item on case insensitivity in section 6
	   should be removed, or clarified to state that
	   all tokens must be sent as upper case.  The
	   latter would also make the comment on case
	   insensitivity comparisons unneeded.
  Also, the ability of an Ident client to do multiple queries is of
  questionable value in most situations where I would imagine Ident
  being used (because normally there will only be one query...).
  However, removing this feature at a later date would not cause
  interoperability problems, so I don't think it is enough of an
  issue to worry about at this time.  I would want to see this issue
  revisited before the document could go to Draft status, and either
  flushed out in greater detail or removed.  Besides, it would be
  easier to remove it at Draft if it is not needed, rather than adding
  it at Draft if it is needed.

To increase interoperability of TAP with RFC-931 and Ident,
the TAP spec should be modified to:
	1) Not allow white space before the <conn-info> part
	   of a USERID reply.

Specific details of interoperability analysis
=============================================

Character quoting:
------------------

   RFC-931 includes the use of a quoting character to allow
   ":", ",", white space, and the quoting character itself ("\")
   to be included in tokens.  Neither Ident or TAP contain this.

   Potential Interoperability problem:
	An Ident or TAP client will not correctly parse a
	response from an RFC-931 server that includes quoted
	characters.  An RFC-931 server will not correctly
	parse a request from an RFC=931 client that includes
	quoted characters.

  Possible rectification:
	There isn't really anything that can be done about this
	issue.  It does seem that existing implementations do not
	support character quoting, if this is the case then there
	is no interoperability issue.

Client query to Server format:
------------------------------

  The only issue here is on white-space.  All three allow white-space
  between the tokens.  Ident also specifically allows white space at
  the beginning and the end of the line.

    RFC-931
	<Server-port><WS>,<WS><Client-port><CR><LF>

    Ident
	<WS><Server-port><WS>,<WS><Client-port><WS><CR><LF>

    TAP
	<Server-port><WS>,<WS><Client-port><CR><LF>

  Potential Interoperability problem:
	An Ident client that sends white-space at the beginning
	or end of the request may confuse an RFC-931 or TAP server.

  Possible rectification:
	Eliminate beginning and trailing white-space from Ident.


Server response to Client format:
---------------------------------

    RFC-931
	<Server-port><WS>,<WS><Client-port><WS>:<WS>USERID<WS>:<WS>
			<opsys><WS>:<info><CR><NL>

	<Server-port><WS>,<WS><Client-port><WS>:<WS>ERROR<WS>:<WS>
			<error-type><WS><CR><NL>

    Ident
	<WS><Server-port><WS>,<WS><Client-port><WS>:<WS>USERID<WS>:<WS>
			<opsys>[<WS>,<WS><charset>]<WS>:<info><CR><NL>

	<WS><Server-port><WS>,<WS><Client-port><WS>:<WS>ERROR<WS>:<WS>
			<error-type><WS><CR><NL>

    TAP
	<Server-port><WS>,<WS><Client-port><WS>:<WS>USERID<WS>:<WS>
			<opsys><WS>:<WS><info><CR><NL>

	<Server-port><WS>,<WS><Client-port><WS>:<WS>ERROR<WS>:<WS>
			<error-type><CR><NL>

  Potential Interoperability problems:
	An Ident Server that sends white-space at the beginning of
	either an ERROR or USERID response, or that sends white-space
	at the end of an ERROR response, may confuse an RFC-931 or
	TAP client.

  Possible rectification:
	Eliminate beginning and trailing white-space from Ident replies.

  Potential Interoperability problems:
	An Ident Server that includes the optional <charset> information
	will have it be taken as part of the <opsys> by an RFC-931 or TAP
	client. (Also, see below for more issues dealing with <charset>.)

  Possible rectification:
	Ident Servers should not include the optional <charset>
	information if OCTET will suffice for the <charset> designation.

  Potential Interoperability problems:
	A TAP Server that includes white-space between the : and
	the <info> will be included as part of the <info> by an RFC-931
	or an Ident client.

  Possible rectification:
	TAP Servers should not send white-space before the <info>,
	unless it is to be included as part of <info>.

Error types:
------------

	RFC-931			Ident			TAP
	================	================	================
	INVALID-PORT		INVALID-PORT		INVALID-PORT
	NO-USER			NO-USER			NO-USER
	UNKNOWN-ERROR		UNKNOWN-ERROR		UNKNOWN-ERROR
				HIDDEN-USER		HIDDEN-USER
				X<non-standard>		X<non-standard>

  Potential Interoperability problems:

	None.  The values are only suggested values in RFC-931,
	hence a compliant RFC-931 client should be able to deal
	with other error types than the 3 types explicitly listed
	in the document.

Operating system types:
-----------------------

	RFC-931			Ident			TAP
	================	================	================
	<from Assigned #s>	<from Assigned #s>	<from Assigned #s>
	OTHER			OTHER			OTHER
	TAC
  In addition, an Ident <opsys> may be followed by <WS>","<WS><charset>
  before the ":" field separator.

  Potential Interoperability problems:
	Ident and TAP clients may receive TAC, and not recognize it
	as a valid operating system type.

  Possible rectification:
	None needed.  The list of operating system types in Assigned
	numbers can grow, so any client must be able to deal with
	unknown operating system types.

  Potential Interoperability problems:
	RFC-931 and TAP clients may receive ","<charset> as part
	of the operating system types when talking to an Ident server.
	Also, if white-space is included before or after the ",", an RFC-931
	or TAP client may not be able to successfully parse the rest
	of the line, as it would be expecting a ":" to be the next
	character.

  Possible rectification:
	An Ident server should not be allowed to insert white-space before
	or after the "," separating the <opsys> and the <charset>.  An RFC-931
	or TAP client would then treat <opsys>","<charset> as the
	<opsys>, and not recognize the operating system type, and would
	just treat it as an unknown operating system type, which they
	both need to be able to do now.


Token character sets:
---------------------

  The Ident spec says that field comparison is done case independent, so
  that, for example,  "Error" and "ERROR" will compare as being equal.
  This is true for all fields except for the <info> field in a USERID
  reply.  Currently, all tokens listed in all three of the documents are
  all upper-case.  The list of operating system types in Assigned Numbers
  is limited to upper-case letters.

  Potential Interoperability problems:
	If an Ident server were to send out a token in a reply with
	lower case letters in a token, it may not be recognized by
	either an RFC-931 or a TAP client, when an Ident client would
	recognize it.  If an RFC-931 or TAP client sent out a reply
	with lower case letters in a token that was different from
	another known token only in its case, then an Ident client
	would incorrectly treat it as the all upper case token.

  Possible rectification:
	Ident servers must not send out tokens with lower case
	letters.  RFC-931 and TAP servers must not send out tokens
	with lower case letters.  The latter is not a problem, because
	currently none of the three documents specify any tokens
	with lower case letters.


Number of queries per connection:
---------------------------------

  RFC-931 and TAP specify that the client sends one query, and
  the server sends one reply.  Ident allows the client to send
  multiple queries, but allows the server to close the connection
  after sending one reply, or wait for additional queries.

  Potential Interoperability problems:
	If an Ident client wishes to do multiple queries, it
	may find that connection is closed, even when talking to an
	Ident server.   Thus, the client has to deal with this
	situation, and should not have any problems dealing with
	an RFC-931 or TAP server that will always close the connection
	after giving one reply, so this is not a problem.

	If an Ident server receives a request from an RFC-931 or
	TAP client, it will process the one request.  If it then
	closes the connection, there is no problem.  If it waits
	for additional queries, it will be notified that there
	is no more data coming when the client closes the connection.
	This is also not a problem.

  Possible rectification:
	Clarification of client actions in Ident would be useful.
	Some possible suggestions:
	     1) An Ident client should not send a second request
		until it has received a response from the first
		request.  (Allows the connection to close down from
		single shot servers, so that the second request
		will fail at the sender side.)
	     2) An Ident server should only use closing the
		connection as a response to the initial request.
		If it sends a response to the first request and
		accepts the second request, it should respond to
		the second request.
	     3) An ident client that gets a closed TCP connection
		as a response to a second query should retry that
		query on a new TCP connection, rather than treating
		it as an error.  (It must do this anyway to deal
		with single-shot servers...)


Other issues:
-------------

  The BNF code in Ident is missing "HIDDEN-USER".